context.Context 的设计目的不是承载业务数据，而是传递取消信号、超时控制和跨 goroutine 的请求生命周期元信息；强行用 WithValue 存储用户 ID、租户 ID 等业务变量会导致类型不安全、key 冲突、调试困难，且违背 Go 官方“仅用于极少变动的请求级元数据”的明确警告。
Context不是用来传全局变量的
直接说结论：context.Context 的设计目的不是承载业务数据，而是传递取消信号、超时控制和跨 goroutine 的请求生命周期元信息。强行往里面塞业务变量（比如用户 ID、租户 ID、trace ID）会导致语义混淆、类型不安全、难以调试，且违背 Go 官方对 context.WithValue 的明确警告：“only for request-scoped data that’s unlikely to change”（仅适用于极少变动的请求级元数据）。
为什么 context.WithValue 看似能用但实际危险
常见错误是这样写：
ctx = context.WithValue(ctx, "user_id", 123) ctx = context.WithValue(ctx, "tenant", "acme")
问题在于：
-
"user_id"这种字符串 key 没有类型约束，取值时必须手动断言：v := ctx.Value("user_id").(int)，一旦类型错或 key 拼错，运行时 panic - 多个中间件或库都往同一个
context写值，key 冲突概率高，且无编译期检查 - 无法静态分析哪些函数依赖哪些上下文值，重构时极易漏掉清理或误删
-
context.WithValue创建新 context 对象，高频写入会增加 GC 压力（虽单次开销小，但量大时可观）
真正该怎么做：显式参数 + 封装结构体
把请求级变量作为函数参数或结构体字段显式传递，才是清晰、可测、可维护的做法。例如：
type RequestData struct {
UserID int64
TenantID string
TraceID string
}
func handleOrder(ctx context.Context, req RequestData) error {
// 直接用 req.UserID，无需从 ctx.Value 取
return processPayment(ctx, req.UserID)
}
如果已有大量代码依赖 context 传参，至少做到：
- 定义私有 key 类型（避免字符串冲突）：
type ctxKey string; const userIDKey ctxKey = "user_id" - 封装存取方法，统一做类型检查：
func WithUserID(ctx context.Context, id int64) context.Context { return context.WithValue(ctx, userIDKey, id) } - 只在最外层（如 HTTP middleware）注入一次，内层函数不再调用
WithValue
哪些场景可以谨慎用 context.WithValue
官方认可的用途非常有限，仅限于：
- OpenTracing / OpenTelemetry 的
span实例（otel.GetTextMapPropagator().Inject内部用） - HTTP 请求中的
*http.Request（req.Context()自带） - 数据库连接上下文（如
sql.Tx的WithContext方法） - 自定义 logger 的
ctx字段（如log.WithContext(ctx)），但 logger 本身应封装好 key 类型
真正的难点不在“怎么塞进去”，而在“谁负责清理、谁负责校验、出错了怎么定位”。一旦开始用 WithValue，就要为整个调用链的类型安全和可读性负全责。
