Context设计初衷是传递取消信号、超时控制和请求级元数据（如traceID），不可用于传业务状态；业务字段应显式通过参数或结构体传递，避免隐式依赖与类型不安全。
Context 不能用来传业务状态，这是根本前提
Go 的 context.Context 设计初衷是传递取消信号、超时控制和跨 goroutine 的请求范围元数据（比如 trace ID），不是为存储业务字段服务的。用 context.WithValue 塞 user.ID 或 tenant.Name 看似方便，但会带来隐式依赖、类型不安全、难以调试等问题——一旦中间件或库擅自修改 context 值，下游就可能 panic 或逻辑错乱。
哪些场景下 context.WithValue 是可接受的
仅限于极少数满足全部条件的情况：
- 值是只读的、不可变的（如
http.Request中的auth.Token） - 键是私有类型（避免与其他包冲突），例如
type userKey struct{}，而非string - 上下游明确约定该 key 的语义和生命周期，且不跨服务边界传播
- 没有更清晰的替代方案（比如函数参数、结构体字段）
示例写法：
type userKey struct{}
func WithUser(ctx context.Context, u *User) context.Context {
return context.WithValue(ctx, userKey{}, u)
}
func UserFromContext(ctx context.Context) (*User, bool) {
u, ok := ctx.Value(userKey{}).(*User)
return u, ok
}
真正该用结构体字段或函数参数传状态
绝大多数业务状态应该显式传递：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中的用户信息，应从 middleware 解析后作为参数传入 handler 函数，而不是塞进 context
- 数据库事务上下文（如
*sql.Tx）应作为方法参数传给 DAO 层，而非藏在 context 里 - 需要跨多层调用的状态，优先封装成结构体（如
type RequestScope struct { TenantID string; Logger *zap.Logger }），再作为第一个参数传入
这样做的好处是：IDE 可跳转、单元测试易 mock、重构时编译器能报错、团队协作无歧义。
Context 传状态时最常踩的三个坑
坑一：用 string 当 key，导致不同包写同一个 key 名覆盖彼此值 —— 必须用未导出的私有类型。
坑二：在中间件中反复调用 context.WithValue 创建新 context，却没保留原始 cancel 函数，造成资源泄漏或取消失效。
坑三：把 context 当成“万能全局变量”，在日志、指标、DB 查询等地方都依赖它取状态，结果一升级某个中间件就崩 —— 这说明设计上已经耦合过深。
真正难的不是怎么往 context 里塞东西，而是判断什么时候不该塞。只要业务字段出现在 context.WithValue 调用里，就该停下来问一句：这个值，是否必须随 cancel/timeout 一起传播？如果不是，它就不属于 context。
