Context.Value 不能替代函数参数传值
用 context.WithValue 往 Context 塞数据，最常踩的坑是把它当成了“全局参数传递通道”。它不是为业务逻辑传参设计的，而是为跨层传递请求生命周期元信息（比如 traceID、用户身份标识）服务的。
常见错误现象：ctx.Value("user_id") 在中间件里塞了，下游 handler 里取不到——因为 Context 被意外替换（比如用了 context.WithTimeout 却没把原 value 拷过去），或者压根没把 ctx 一路透传下去。
- 只存只读、低频、与请求生命周期强绑定的元数据，比如
"trace_id"、"request_id"、"auth_user" - 绝不存业务实体（如
*User、map[string]interface{}）、配置对象或可变状态 - 键必须是自定义类型（避免字符串冲突），例如
type userKey struct{}，而不是"user" - 调用链中每层都必须显式把 ctx 作为第一个参数传入，且不擅自创建新 context（除非明确需要 cancel/timeout）
Value 类型擦除导致运行时 panic
context.Value 返回 interface{}，类型断言失败会直接 panic。这不是设计缺陷，而是提醒你：这里本不该承载关键业务数据。
使用场景：你确实需要在日志中间件里取一个 trace_id 打日志，但这个 key 可能在任意一层被漏设，或被设成 int 而不是 string。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次取值必须做双断言：
v, ok := ctx.Value(key).(string)，ok为 false 时要有 fallback 或明确报错 - 不要依赖 IDE 自动补全来“猜”类型，
ctx.Value的返回值永远是interface{} - 如果发现要频繁做
.(MyStruct)断言，说明该数据不该放 Context，应该走函数参数或结构体字段
WithValue 性能开销比想象中大
每次调用 context.WithValue 都会新建一个 context 实例，并在内部维护一个链表式存储。高频写（比如在 for 循环里反复塞值）会触发内存分配和 GC 压力，而且查找是 O(n) 时间复杂度。
性能影响：在 QPS 上万的 HTTP handler 中，如果每个请求都调用 5 次 WithValue，实测可能增加 3%~8% 的 P99 延迟（取决于 value 大小和链长度）。
- 一个请求生命周期内，
WithValue最好只调用 1~2 次，集中在入口（如 middleware）完成所有元数据注入 - 避免嵌套调用：
ctx = context.WithValue(ctx, k1, v1); ctx = context.WithValue(ctx, k2, v2)—— 这会构造两层 wrapper - 如果真需要多个键值对，考虑封装成一个结构体一次性塞入：
context.WithValue(ctx, metaKey, &RequestMeta{TraceID: ..., UserID: ...})
测试时容易漏掉 Context 传递路径
单元测试里 mock 一个空 context（context.Background()）就跑，结果线上崩了——因为真实调用链中某一层悄悄改写了 context，而你的 test 没覆盖到那条路径。
典型错误：HTTP handler 测试只传 context.Background()，但生产环境经过 gin/zap/middleware 后，ctx 已携带 trace_id 和 user；测试时取值失败，却误以为是逻辑 bug。
- 测试中模拟真实 context 链路：用
context.WithValue显式注入必要 key，哪怕只是填空字符串 - 对依赖
ctx.Value的函数，加一行防御性检查：if ctx == nil { return errors.New("context is nil") } - 静态检查工具（如
staticcheck）能抓出未使用的ctx.Value调用，但抓不出“该取没取”，这点只能靠测试覆盖
Context.Value 的真正作用不是帮你省掉几个参数，而是让横切关注点（tracing、auth、logging）能穿透业务层而不污染接口。一旦开始用它传业务字段，就等于把耦合从显式参数挪到了隐式 runtime 查找上——问题不会消失，只会更难 debug。
