context.Context 必须显式作为参数传入每个函数：它不是全局变量或隐式状态，需逐层传递；跳过某层、闭包捕获或包级缓存会导致取消失效、超时丢失、ctx.Value 返回 nil 或 cancel 后 goroutine 未停止。
context.Context 必须显式作为参数传入每个函数
Go 的 context.Context 不是全局变量，也不是隐式可访问的运行时状态。它必须像普通参数一样，逐层、显式地传给每一个参与请求链路的函数。任何跳过某一层、靠“闭包捕获”或“包级变量缓存”的做法，都会导致取消失效、超时丢失或值查找失败。
常见错误现象包括：
- 下游函数调用
ctx.Value(key)返回nil，即使上游已设置 - 手动调用
cancel()后，goroutine 仍在运行（未监听） - HTTP handler 中新建
context.Background()，导致整个链路脱离父请求生命周期
正确方式就是：每个中间函数签名都带 ctx context.Context 参数，并在调用下一级时原样或派生后传入。
嵌套中不要用 string 做 key，必须用自定义类型
当你在多层函数中通过 context.WithValue 传递数据（如 userID、traceID），key 的类型决定了是否会发生键冲突或类型断言失败。用 string 作 key 是高危操作——不同包、不同模块可能无意中用了相同字符串，导致值被意外覆盖或读错。
立即学习“go语言免费学习笔记（深入）”；
应该定义私有空结构体作为 key：
type userIDKey struct{}
然后统一使用：
ctx = context.WithValue(ctx, userIDKey{}, u.ID)if id, ok := ctx.Value(userIDKey{}).(int64); ok { ... }
这样能保证 key 的唯一性与类型安全。编译器会阻止你把 userIDKey{} 和另一个 traceIDKey{} 混用。
避免在 struct 字段里长期持有 context.Context
有人为了“省事”，把 ctx context.Context 存进某个 service struct 里，后续方法直接从字段取。这是严重反模式。
原因很直接：
- context 是不可变的，每次
WithValue或WithTimeout都返回新实例，旧 struct 字段里的 ctx 就“过期”了 - 如果该 struct 生命周期长于请求（比如单例 service），它持有的 ctx 可能早被取消，但字段没更新，导致
Done()永远不关闭 - goroutine 泄漏风险：子 context 被取消后本该被 GC，但 struct 强引用着它，就卡住了
所有 I/O 操作（http.Client.Do、sql.DB.QueryContext、time.Sleep）都必须接收当前有效的 ctx 参数，而不是从 struct 里拿。
深度嵌套时 value 查找性能不是瓶颈，但链太长要警惕
ctx.Value(key) 的实现是链式遍历：从当前 valueCtx 开始，逐级向上调用 parent.Value(key)，直到找到或抵达 emptyCtx。理论上每层增加一次指针解引用，开销极小（纳秒级）。
但真正需要注意的是语义混乱风险：
- 超过 3–4 层
WithValue嵌套，很难追踪哪个函数设置了什么 key、谁覆盖了谁 - 多个中间件各自塞自己的 key，容易命名冲突或逻辑耦合
- 调试时
fmt.Printf("%+v", ctx)看不到实际内容，因为valueCtx没实现友好的String()
建议：只用 WithValue 传必要元数据（traceID、userID、requestID），业务实体对象别往里塞；复杂数据用独立参数传，别依赖 context “偷渡”。
