context.WithValue仅适用于传递请求级不可变元数据，如用户ID、追踪ID；禁用作全局变量、存配置或可变状态；key须用私有类型防冲突；链路过长致性能下降；查不到值主因是context未正确传递。
context.WithValue 不是通用键值存储
它只适合传递请求范围的、不可变的元数据，比如用户 ID、追踪 ID、请求 ID。拿它存配置、数据库连接或可变状态，等于把 context 当全局变量用，迟早出问题。
- 值必须是线程安全的；如果传了
map或slice，下游并发修改会引发 panic 或数据错乱 - key 类型强烈建议用自定义未导出类型（如
type userIDKey struct{}），避免字符串 key 冲突 —— 两个包都用"user_id"当 key，后塞的值会覆盖前一个 - 不要用
int、string等基础类型做 key，Go 官方文档明确警告过类型冲突风险
链路追踪中传 traceID 的标准写法
OpenTracing / OpenTelemetry 生态里，context.WithValue 是透传 traceID 和 span 的底层手段，但你不该自己拼接 key 或手动生成字符串。
- 用官方 SDK 提供的
otel.GetTextMapPropagator().Inject()注入，Extract()解析，而不是手动塞context.WithValue(ctx, traceKey, "xxx") - 如果你非得手写（比如调试或轻量场景），key 必须是私有类型：
var traceIDKey = struct{}{}，值用string或otel.TraceID原生类型 - HTTP 中间件里取 header 后，应立刻用
context.WithValue封装进 ctx，后续所有子 goroutine 都从 ctx 拿，别缓存到局部变量里 —— 一旦协程被调度，ctx 可能已失效
为什么 WithValue 链太长会导致性能下降
每次调用 context.WithValue 都会新建一个 context 实例，底层是链表结构。10 层嵌套后，ctx.Value(key) 要遍历 10 次才能找到目标值，且所有中间节点都逃逸到堆上。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 高频路径（如每秒万级请求的 API）里，避免在 for 循环内反复调用
context.WithValue - 不要用它传临时计算结果，比如
context.WithValue(ctx, "duration", time.Since(start))—— 这类信息应该由 metrics 或日志系统统一收集 - 如果真需要多层透传多个字段，考虑封装成一个结构体一次性塞进去：
context.WithValue(ctx, dataKey, &RequestData{UID: uid, TraceID: tid})，比 5 次 WithValue 更轻量
Value 查不到的三个最常见原因
不是代码写错了，就是 context 传丢了 —— 而后者更隐蔽。
立即学习“go语言免费学习笔记（深入）”；
- goroutine 启动时用了
go fn()而没传 context，导致新协程拿到的是context.Background()，自然没有你塞的值 - 调用了第三方库的异步方法（比如
sql.DB.QueryRowContext以外的旧版QueryRow），它不接受 context，也就不会向下传递 - 中间件顺序错了：比如 auth middleware 在 log middleware 之后才往 ctx 塞
userID，那 log 里就取不到
查不到时先打一行 fmt.Printf("ctx: %+v\n", ctx)，看是不是已经退化成 emptyCtx 或 background —— 那基本就是上游根本没传进来。
