Go context 要不要放到结构体里？这类场景最好别存

Go 里的 context.Context 咱做Go开发的平时基本都不建议长期塞到业务结构体里。它本质更像「一次请求、一段调用链」的边界参数：从入口处创建，顺着函数调用一路往下传，请求结束后自然就失效了。把 ctx 存成结构体字段，看起来能少写个传参步骤，实际很容易把超时、取消信号和请求级数据，捎带到完全不该关联的下一次调用里，真出了隐式bug排查起来特别头疼。

把 context 当请求边界，而不是对象状态

context 最顺手的用法，就是把它放在函数参数的第一个位置。HTTP 请求进来时生成一个 ctx，业务服务、仓储层、外部接口调用都接收这个 ctx，一旦请求取消或超时，下游逻辑能第一时间停下来不用空跑浪费资源。

这是非常清爽的边界约定：请求开始，ctx 才出现；请求结束，ctx 也跟着结束。但结构体不一样，它通常存活时间久很多，大概率会被多个请求重复使用。把短生命周期的临时参数塞进长生命周期对象里，后面出问题的时候你根本没法一眼定位根源。

为什么大家会想把 ctx 存起来

把 ctx 放进结构体的诱惑特别真实。比如一个服务对象有十几个方法，每个方法都要传 ctx，看起来重复度特别高；或者某个客户端封装里每次调用都要带差不多的超时设置，于是有人就想偷懒写成下面这样：

type OrderService struct {
    ctx  context.Context
    repo *OrderRepo
}

func (s *OrderService) Create(req CreateOrderRequest) error {
    return s.repo.Save(s.ctx, req)
}

这段代码短期看确实少传了一个参数，时间一长就把调用边界完全藏住了。调用 Create 的人根本不知道这个 ctx 是哪来的，也不清楚它有没有被取消、有没有过期、是不是上次请求剩下来的。

典型写法：ctx 从入口向下传

更通用也更稳妥的写法，是让结构体只存稳定不变的依赖，把 ctx 留在方法参数里传递。结构体里放数据库连接、配置、日志器、HTTP 客户端都完全没问题；ctx 这种请求级的临时状态，就该由调用者在每次发起动作的时候传进来。

type OrderService struct {
    repo *OrderRepo
}

func (s *OrderService) Create(ctx context.Context, req CreateOrderRequest) error {
    return s.repo.Save(ctx, req)
}

type OrderRepo struct {
    db *sql.DB
}

func (r *OrderRepo) Save(ctx context.Context, req CreateOrderRequest) error {
    rows, err := r.db.QueryContext(ctx,
        "select order_id from orders where user_id = ? limit 1",
        req.UserID,
    )
    if err != nil {
        return err
    }
    defer rows.Close()
    return nil
}

这样写虽然多传了一个参数，但整条调用链路明明白白：谁发起这次业务动作，谁负责把上下文传下去。数据库、RPC、HTTP 请求也能共享同一个取消信号，逻辑走得通也看得懂。

把 context 存进结构体的反例

真正容易踩坑的场景，是结构体本身就会被反复复用。比如一个 Worker 常驻内存，要处理好多任务；如果它初始化的时候就存了一个 ctx，后续所有任务都会共用同一个取消信号。某个任务超时取消之后，后面所有新任务都会被误伤到。

type Worker struct {
    ctx context.Context
}

func (w *Worker) Handle(job Job) error {
    select {
    case 

如果 Worker 的生命周期比单个任务长，这个设计就相当危险。正确的做法通常是让每个任务带上自己的 ctx，或者在 Handle 里为这次任务单独创建带超时的子上下文。

这样做会带来哪些后果

把 ctx 存进结构体，最直观的后果就是生命周期完全乱套。对象还在正常运行，但上下文早就被取消了；请求早就结束了，但请求里带的自定义值还挂在对象上；测试里只是换了个用例执行顺序，结果因为残留的旧 ctx 把新用例也搞崩了，排查半天根本想不到ctx的锅。

判断清单：什么时候传，什么时候别存

遇到设计拿不准的时候，可以用下面这张清单快速判断：

• 这个 ctx 是否只属于一次请求、一次任务、一次命令执行？如果是，就老老实实传参数。
• 这个结构体是否会被多个请求或多个任务复用？如果是，绝对不要存 ctx。
• 方法是否需要支持超时、取消、trace、日志字段？如果是，把 ctx 明明白白写进方法签名里。
• 结构体里保存的是不是稳定依赖，比如数据库、缓存、客户端、配置？这些完全可以存。
• 如果短暂持有 ctx，能不能百分百证明它不会跨请求、跨任务、跨 goroutine 生命周期？证明不了就别存。

实际项目里，大家更愿意接受“多传一个参数”的啰嗦，也不想让取消信号藏在对象字段里当暗雷。Go 代码的可读性，很多时候就来自这种明明白白的显式边界。

常见问题

context.Background() 可以放到结构体里吗？

多数情况下完全没必要。context.Context 本身直接在调用点用就行，放进结构体不会带来什么额外价值，反而把方法边界搞模糊了。

logger 从 context 里取字段，结构体还能保存 logger 吗？

可以保存稳定的 logger 实例，但请求级字段最好在调用时从 ctx 派生出来。不要把带请求专属字段的 logger 当成长生命周期字段到处复用。

HTTP handler 结构体里能不能保存 request.Context()？

不建议。request.Context() 只属于当前这一次请求，就该在当前请求的调用链里传递。handler 结构体通常会被成千上百个请求复用，不能把某一次请求的上下文存进去。

有没有可以临时持有 context 的场景？

有，但要把生命周期卡得非常死。比如某个只为单次请求创建的短生命周期对象，可以短暂持有 ctx；只要对象有一丁点可能被复用，就老老实实改成参数传递。

小结

context.Context 的重点从来不是省那点传参的功夫，而是用来表达一次调用链的取消、超时和请求级信息。稳定依赖放结构体，请求上下文走参数，这个边界画得越清楚，代码越不容易被旧取消信号、请求值泄露和隐式状态拖垮。遇到拿不准的场景，优先选显式传 ctx，基本不会出大问题。