context.WithValue传值必须用未导出自定义类型作key，如type userKey struct{}，禁用字符串或整数；取值须用v, ok := ctx.Value(key).(T)双返回值断言防panic；仅传轻量不可变元数据，且需显式传递新ctx至下游。
Go context.WithValue 传值必须用自定义类型作 key
直接用字符串或整数当 context.WithValue 的 key，看似能跑通，但极易引发键冲突——不同包、不同模块都可能往同一个 context 里塞 "user_id"，结果取出来的是别人塞的值。Go 官方文档明确建议：key 必须是**未导出的自定义类型**，靠类型系统隔离作用域。
正确做法是定义一个私有结构体或空 struct：
type ctxKey string
const userCtxKey ctxKey = "user"
// 或更轻量：
type userKey struct{}
var userKeyKey userKey
然后传入：ctx = context.WithValue(ctx, userKeyKey, u)。这样即使另一包也定义了 userKey，只要不是同一包下的类型，就无法互相覆盖或误读。
context.Value 返回 interface{}，必须显式断言类型
context.Value 的返回值是 interface{}，不强制类型检查，运行时 panic 是常见错误来源。比如存的是 *User，取的时候写成 u := ctx.Value(userKeyKey).(User)（少了个 *），就会触发 panic: interface conversion: interface {} is *main.User, not main.User。
立即学习“go语言免费学习笔记（深入）”；
安全写法永远用「逗号 ok」语法：
if u, ok := ctx.Value(userKeyKey).(*User); ok {
// 使用 u
} else {
// 处理缺失或类型不符，比如返回 http.StatusUnauthorized
}
- 不要依赖 defer 恢复 panic 来兜底，context 值缺失应是可预期的控制流分支
- 如果 key 对应值可能为 nil，断言后还需判空：
if u != nil { ... }
WithValue 不是通用状态传递工具，只适用于跨 API 边界的元数据
context.WithValue 设计初衷是传递请求生命周期内的**不可变元数据**，比如 trace ID、用户身份、请求优先级。它不是替代函数参数或结构体字段的捷径。
滥用典型场景：
- 把业务实体（如
Order、PaymentService）塞进 context，导致函数签名失真、单元测试难 mock - 在中间件里反复
WithValue覆盖同个 key，掩盖了值被意外篡改的问题 - 用 context 传配置项（如数据库 timeout），实际应通过依赖注入或配置结构体传入
性能上，WithValue 每次调用都会新建 context 实例，底层是链表结构，频繁写入会增加 GC 压力。一次请求中建议 key 数量控制在 3–5 个以内。
调试 context 传值断裂，优先检查中间件是否丢失 ctx
常见现象：上游塞了值，下游 ctx.Value 返回 nil。90% 情况不是 WithValue 本身问题，而是中间层没把新 context 传下去。
典型漏点：
- HTTP handler 中调用 service 方法时，仍传入原始
r.Context()，而非中间件增强后的ctx - goroutine 启动时直接捕获外层 ctx 变量，但该变量后续被重新赋值（应传参进去）
- 使用第三方库（如 sqlx、zap）时，未调用其支持 context 的方法（如
db.QueryRowContext而非db.QueryRow）
快速验证：在关键节点打日志，输出 fmt.Printf("ctx value: %+v\n", ctx.Value(userKeyKey))，比加断点更快定位断裂位置。
真正麻烦的从来不是怎么塞值，而是谁在哪个 goroutine 里改了它、又有没有传下去——context 是隐式链，一环松动，全链失效。
