为什么不建议把 Context 保存进结构体，例外场景是什么

在 Go 项目里，context.Context 经常从 HTTP handler 一路传到数据库、RPC 或后台 goroutine。把它放进业务结构体看起来省事，实际却容易把一次请求的生命周期绑定到一个可能长期复用的对象上。

先说结论：普通业务对象不要保存 Context，应该把 ctx 作为需要它的方法的第一个参数。这样每次调用都能拥有独立的取消信号、deadline 和请求级值。只有在兼容旧 API、且 Context 明确只属于一次请求对象时，结构体字段才可能是有边界的例外。

官方地址：https://pkg.go.dev/context

Context 应该跟着一次调用走

一个清晰的接口应该让调用者一眼看出 Context 影响哪次工作：谁传入，谁决定何时取消；方法返回后，这次 Context 的职责也随之结束。推荐的形状如下：

type Worker struct{}

func (w *Worker) Fetch(ctx context.Context, key string) error {
    // 中文说明：ctx 只约束本次 Fetch，调用方可以单独设置超时。
    return loadFromStore(ctx, key)
}

func (w *Worker) Process(ctx context.Context, key string) error {
    // 中文说明：Process 可以拥有另一套取消和请求级元数据。
    return publishResult(ctx, key)
}

如果 Fetch 和 Process 都读取 w.ctx，调用者就无法只取消其中一个操作，也无法为某一次数据库查询缩短预算。Context 的第一个参数位置还会形成稳定的 API 习惯，静态分析工具也更容易发现传播中断、漏传或没有调用取消函数的问题。

把 Context 存进结构体，问题出在生命周期错位

下面这种写法的问题不在语法，而在于构造函数把“创建对象时的请求”偷偷变成了“所有方法的请求”：

type Worker struct {
    ctx context.Context
}

func NewWorker(ctx context.Context) *Worker {
    // 中文说明：这里把一次调用的生命周期固定到了 Worker 上。
    return &Worker{ctx: ctx}
}

func (w *Worker) Process(key string) error {
    // 中文说明：无法从调用点看出这个操作使用了哪一个 deadline。
    return publishResult(w.ctx, key)
}

这会产生四个具体风险：

• 请求共享：同一个 Worker 被多个请求复用时，方法之间失去独立取消能力。
• deadline 过期：对象创建时的短 deadline 可能早已结束，后续调用一开始就得到 context deadline exceeded。
• 构造语义含混：调用者会猜测 NewWorker(ctx) 是否真的执行了需要取消的工作。
• 值的边界模糊：租户、追踪 ID 等请求值可能被错误地带入下一次无关调用。

可以用下面的表快速判断一个 Context 是否放错了位置：

什么情况下结构体里保存 Context 可以接受

例外通常不是“这个对象很方便”，而是为了保持已有 API 的兼容性。如果旧方法已经是 Do(req)，直接改成 Do(ctx, req) 会破坏调用方。此时可以让 Context 绑定到一次性的 Request，并把请求生命周期写进类型和文档里。

这类对象要满足三个条件：它代表一次请求而不是长期服务；Context 只在该请求的生命周期内使用；创建函数或构造方法明确说明取消、deadline 和值会影响哪些操作。即便如此，新增 API 仍优先采用带 Context 的方法，例如保留旧方法，再增加 CallContext(ctx)，由旧方法使用明确的根 Context 转发。

因此，net/http.Request 不能被简单拿来证明“Context 放进任何 struct 都可以”。它是围绕一次 HTTP 请求设计的对象，字段的作用域与请求本身一致；业务里的连接池、服务、仓储和 Worker 通常会被长期复用，生命周期完全不同。

提交代码前的 Context 设计检查

1. Context 是否是方法的第一个参数，并且命名为 ctx。
2. 这个对象是否会跨请求复用；如果会，就不要把请求 Context 放进字段。
3. 下游数据库、HTTP 或 RPC 调用是否继续接收同一个 ctx，而不是重新使用 Background()。
4. 每个 WithCancel、WithTimeout 或 WithDeadline 是否由创建方调用了 cancel。
5. 如果为了兼容而保存 Context，是否能证明对象只代表一次请求，并且没有被池化复用。

延伸问题

Context 可以作为结构体的普通配置字段吗？

不建议。超时、取消和请求值属于动态调用状态；固定配置应使用独立字段，避免和 Context 的生命周期混在一起。

把 Context 放进接口实现会更方便吗？

通常不会。让接口方法接收 ctx 更容易测试、替换和控制每次调用的边界。

后台任务需要脱离请求怎么办？

先明确它是否真的应该脱离，再创建独立且有上限的 Context；不要把原请求 Context 长期藏进服务对象。

判断这条规则时，关键不是记住“struct 禁止 Context”这句口号，而是检查作用域是否一致：一次调用就传参，长期对象就不持有请求状态；只有为了兼容旧接口，才让一次性请求对象承担 Context。