context.WithValue不可传业务参数，只限传递不可变元数据；key须为私有类型如type userKey struct{}；值禁止用指针或map；链式调用需避免堆积。
context.WithValue 传业务参数会破坏可测试性
把 userID、config.DB 这类核心业务参数塞进 context.WithValue，后续几乎没法写可靠单元测试。因为测试时你得手动构造完整 context 链，还要确保中间没漏掉某层 WithValue 调用；一旦 handler 内部又调了另一个依赖 context 的函数，测试就变成拼图游戏。
更麻烦的是：这类值通常没有默认 fallback，ctx.Value(key) 返回 nil 后直接类型断言会 panic，比如 ctx.Value(userKey{}).(string) 在测试里没塞值就崩。
- 优先显式传参：
func handleOrder(ctx context.Context, userID string, db *sql.DB) - 若必须透传，只限请求元数据（
traceID、requestID、authScope） - 测试时用
context.WithValue(context.Background(), key, "test-123")注入，但别让它成为主逻辑依赖
key 用 string 或 int 就等于埋雷
用 "user_id" 或 1 当 key，看似省事，实则在多人协作或引入第三方库时极易冲突。两个包都执行 context.WithValue(ctx, "user_id", "abc")，后写的会覆盖前写的，且编译器完全不报错。
Go 运行时只检查 key 是否满足 comparable 约束，不检查语义唯一性——而 string 和 int 天然可比较，所以能过，但后果严重。
- 正确做法：定义未导出私有类型，如
type userKey struct{} - 绝对不要用
var UserKey = "user_id"这种公开变量，它本质还是 string - 空 struct
struct{}是最轻量安全的选择，既不可导出，又零内存占用
传指针或 map/slice 会引发竞态和内存错误
context.WithValue 设计上只接受不可变、可比较、轻量的值。传 &user 或 map[string]string{} 看似能跑通，但实际危险：
- 栈上变量取地址后传入 context，协程稍晚执行时该地址可能已失效
- 多个 goroutine 并发读写同一个 map，触发
fatal error: concurrent map writes - context 语义是只读的，但指针内容可变，违背设计契约
值类型应严格限制为：string、int、bool、自定义不可变 struct（所有字段导出且无指针字段），或封装好的 value 类型如 type UserID string。
链式 WithValue 堆积导致性能下降
每次调用 context.WithValue 都新建一个 context 实例，底层是单向链表。10 层嵌套后，一次 ctx.Value(key) 要遍历 10 个节点；高频路径（如每秒万级请求）下，P99 延迟实测增加 3%~8%。
- 入口中间件一次性注入所有元数据，别在 for 循环或子函数里反复调用
- 需要多个字段时，封装成结构体一次性塞入：
context.WithValue(ctx, metaKey, &RequestMeta{UID: u, TraceID: t}) - 避免
ctx = context.WithValue(ctx, k1, v1); ctx = context.WithValue(ctx, k2, v2)这种写法
最常被忽略的一点：context 丢失比值取不到更难排查——goroutine 启动时忘了传 context，或调用了不支持 context 的老版 SDK（比如 sql.DB.QueryRow 而非 QueryRowContext），此时你查半天 ctx.Value 为什么是 nil，其实根本没传进去。
