最常见原因是取值未做类型断言检查或key非法（如用string/map作key），导致ctx.Value(key)返回nil后强转panic；key必须是可比较类型（推荐struct{}），取值务必用v, ok := ctx.Value(k).(T)防御性写法。
为什么 context.WithValue 一用就 panic？
最常见原因是取值时没做类型断言检查，或 key 类型不匹配导致 ctx.Value(key) 返回 nil，再强转就直接 panic。比如：ctx.Value("user_id").(string) —— 字符串 key 不仅可能被其他包覆盖，返回值还可能是 nil，强转必然崩溃。
更隐蔽的是 key 本身非法：用指针、map、slice 或含这些字段的 struct 当 key，运行时会 panic：context: key must be comparable。Go 只允许 comparable 类型作 key，而 struct{} 是最安全的选择。
- 永远别用
"user_id"、1、"trace_id"这类字面量当 key - 定义私有未导出类型，如
type userIDKey struct{}，哪怕空 struct 也比字符串强 - 取值必须带判断：
if uid, ok := ctx.Value(userIDKey{}).(string); ok { ... }
哪些值绝对不能塞进 context.WithValue？
不是所有“看起来能塞”的东西都该塞。核心原则：只存请求级、不可变、小体积、只读元数据。一旦越界，轻则逻辑错乱，重则内存泄漏或竞态。
- 禁止传指针（如
&user）：指向栈变量时可能悬垂；并发修改破坏只读语义 - 禁止传配置、DB 连接、HTTP client、logger 实例：它们是依赖项，该走参数或依赖注入，不是靠 context 查找
- 禁止传 map/slice/func：非 comparable 类型不能作 key；且这些值可变，违反上下文设计初衷
- 避免传结构体指针，改用值类型或封装成只读 struct（如
type UserID string）
链式 WithValue 为什么让 P99 延迟升高？
每次调用 context.WithValue 都新建一个 wrapper 节点，底层是单向链表。查值时从头遍历，5 层嵌套就要比 1 层多 4 次指针跳转和 interface{} 解包。在 QPS 上万的 handler 中，实测延迟增加 3%~8%。
- 高频路径（如 for 循环、日志打点）里禁用
WithValue - 中间件入口一次性注入所有元数据，别拆成多次调用
- 真要传多个字段，封装成结构体一次塞入：
context.WithValue(ctx, metaKey, &RequestMeta{UID: uid, TraceID: tid}) - 别在 goroutine 启动时漏传 ctx ——
go fn()用的是context.Background()，你塞的值根本不存在
查不到值，八成不是代码写错了
多数时候不是 ctx.Value(key) 写得不对，而是 context 根本没传到那。这个 bug 极难复现，因为表现是“有时有、有时无”，尤其在异步调用链中。
- 第三方库用了旧版 API（如
sql.DB.QueryRow而非QueryRowContext），不接受 ctx，自然不向下透传 - goroutine 启动时忘了把 ctx 传进去，新协程拿到的是干净的
context.Background() - 中间件里调了
WithValue，但 handler 拿的是原始 request.Context()，不是中间件加工后的 ctx
真正麻烦的是：这种丢失没有编译错误，也没有 panic，只有值为 nil 导致下游逻辑静默失败。上线后才在特定流量路径上暴露，调试成本极高。
