Context.Value 的 key 必须是可比较的自定义类型（如 type key struct{}），不可用字符串或不可比较类型；value 应只传不可变小数据，取值必须用 v, ok := ctx.Value(k).(T) 防 panic。
Context.Value 为什么不能传结构体或指针
因为 context.WithValue 内部用的是 interface{}，但 Go 的 context 包明确要求 key 必须是可比较的（comparable），且官方文档强烈建议用自定义类型而非字符串——否则容易键冲突、类型丢失、无法做类型安全检查。
常见错误现象：panic: context value not comparable（传了 map/slice/func）；或者取值时类型断言失败却没报错，后续 panic 在别处，排查困难。
- key 必须是导出的未命名类型，比如
type requestIDKey struct{}，再声明var reqIDKey requestIDKey - value 推荐只传不可变小数据：
string、int64、time.Time，或你完全控制生命周期的轻量结构体（必须所有字段都可比较） - 别传
*sql.Tx、http.Request、map[string]interface{}这类——它们要么不可比较，要么生命周期难管理，要么引发内存泄漏
如何安全地从 Context 取值并避免 panic
直接 ctx.Value(key) 返回 interface{}，强制类型断言（v.(MyType)）在值不存在或类型不匹配时会 panic。生产环境必须用「逗号 ok」语法做防御性判断。
使用场景：中间件注入 traceID、用户身份、租户 ID 后，在 handler 或下游 service 中读取。
立即学习“go语言免费学习笔记（深入）”；
- 永远写成
v, ok := ctx.Value(myKey).(string)，而不是v := ctx.Value(myKey).(string) - 如果 value 是自定义结构体，确保它实现了
fmt.Stringer或有明确的零值逻辑，方便日志和 fallback - 不要在循环里反复调用
ctx.Value——虽然开销小，但语义上表示“这个值不该频繁查”，应提前提取到局部变量
userID, ok := ctx.Value(userKey).(int64)
if !ok {
log.Warn("missing user ID in context")
return errors.New("unauthorized")
}
Context.Value 和依赖注入（DI）的边界在哪
Context.Value 不是通用状态传递机制，它的设计初衷只有两个：取消（Done()）和超时（Deadline()），value 是附带功能，且性能和可维护性代价很高。
容易踩的坑：把 Context.Value 当成全局变量或 DI 容器用，结果导致函数签名干净但行为隐晦、单元测试难写、重构时不敢动上下文链路。
- 只传请求生命周期内**只读、跨层、少量**的数据：traceID、auth token（解析后）、region、requestID
- 业务逻辑需要的 service 实例（如
*UserService）、配置、缓存客户端——应该通过构造函数或参数显式传入 - 如果某个 handler 里要取 3 个不同 key 的值，大概率说明你该重构：把相关数据提前聚合进一个结构体，用自定义 context 类型封装（比如
type RequestContext struct { ctx.Context; User User; Tenant Tenant }）
为什么用 string 类型做 key 是最危险的习惯
字符串 key 看似简单，实际等于放弃类型安全和 IDE 支持。两个包各自定义 "user_id"，但含义不同，运行时才暴露冲突，而且没法做静态检查。
性能影响不大，但可维护性灾难：grep 找不到所有使用点（大小写/空格/拼写差异），重构 rename 会漏掉 context 里的字符串字面量。
- 必须用私有类型做 key：
type userIDKey struct{}+var userIDKey userIDKey - key 类型建议定义在共享包（如
pkg/contextkeys），避免各模块重复定义 - 别为了“省事”在测试里用字符串 key —— 测试也该走同一条安全路径，否则上线才崩
真正麻烦的从来不是怎么塞进去，而是谁在哪个 goroutine 里删掉了它、谁覆盖了它、谁忘了设它。Context.Value 的链路是隐式的，而隐式的东西，总在你以为它稳的时候掉链子。
