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 次才能找到目标值，且所有中间节点都逃逸到堆上。
- 高频路径（如每秒万级请求的 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 —— 那基本就是上游根本没传进来。
