必须用未导出类型作 context.WithValue 的 key，如 type userIDKey struct{}；直接用 string/int 会导致跨包 key 冲突；需确保新 ctx 被传递下去，取值必须用 v, ok := ctx.Value(key).(type) 判断；多值应聚合为结构体单次注入；仅用于传递请求级只读元数据。
context.WithValue 传值必须用未导出类型作 key
直接用 "user_id" 或 int(1) 当 key，运行时可能悄无声息地覆盖或读错值——不同包里同名字符串 key 在底层是同一地址，ctx.Value("user_id") 取到的可能是鉴权中间件设的，也可能是日志中间件覆盖后的。Go 官方和所有生产级代码都要求 key 是未导出类型。
正确写法是定义一个空 struct 类型，并保持未导出：
type userIDKey struct{}
var UserIDKey = userIDKey{}
然后使用：ctx = context.WithValue(ctx, UserIDKey, "u_12345")。这样即使另一个包也定义了 userIDKey，只要类型未导出，编译器就认为它们不等价，不会冲突。
- 禁止用
string、int、interface{}等内置类型直接作 key - 禁止在多个文件里重复声明
type UserKey string—— 每次声明都是新类型，无法跨文件识别 - key 类型本身不需要字段，
struct{}足够；变量名（如UserIDKey）可导出供其他包使用
ctx.Value(key) 返回 nil 或 panic 的真实原因
最常见错误不是 API 写错了，而是你没意识到：context.WithValue 不修改原 ctx，它返回一个全新 context 实例。如果调用后没把新 ctx 传下去，下游拿到的仍是旧 ctx，ctx.Value(UserIDKey) 必然返回 nil。
立即学习“go语言免费学习笔记（深入）”；
HTTP 中间件里尤其高发：写了 ctx = context.WithValue(r.Context(), UserIDKey, id)，但忘了 r = r.WithContext(ctx)；Gin 用户还要注意：c.Request.Context() 是只读副本，必须显式赋值：c.Request = c.Request.WithContext(newCtx)。
- 取值永远用双返回值：
v, ok := ctx.Value(UserIDKey).(string)，跳过ok判断会 panic - 如果值可能是
nil（比如传了*User），加一层非空检查：if v != nil && ok - 强烈建议封装工具函数，例如：
func GetUserID(ctx context.Context) (string, bool)，内部统一处理类型断言和空值
传多个值别链式 WithValue，打包再注入
连续三次 context.WithValue 会构造三层嵌套的 valueCtx，每次 Value() 查找都要遍历链表，性能随嵌套深度线性下降，且 key 管理混乱、难以调试。
正确做法是把多个请求元数据聚合成一个不可变结构体，单次注入：
type reqMeta struct {
ID string
Lang string
TenantID int64
}
var metaKey = struct{}{}
ctx = context.WithValue(ctx, metaKey, reqMeta{ID: "req-abc", Lang: "zh-CN"})
- 结构体字段应全部小写（只读语义），避免外部修改
- 禁止传指针、map、slice 或大结构体——易引发 data race，且
Value()查找开销大 - 若元数据来自不同中间件，由最上游统一收集并注入，下游只读不覆盖
WithValue 不是函数参数替代品，只承载请求级元数据
context.WithValue 的唯一合法用途，是传递整个请求生命周期内都有效、各层中间件都可能需要的轻量只读标签，比如 requestID、traceID、userID。它不是为了省几个函数参数而设计的。
一旦你开始用它传配置对象、数据库连接、服务实例或可变状态，就会立刻掉进 data race、生命周期错乱、测试困难的坑里。这些该走显式参数，或者依赖注入容器。
- 业务逻辑函数必须显式声明所需参数，不能靠
ctx.Value隐式获取 - 传入的值必须不可变；若需“更新”，应重建新 struct + 新 ctx，而非修改原值
- 每个 key 应有明确定义的设置者（谁注入）、读取者（谁消费）、不变性契约（何时设、是否必设）
