context.Value 应谨慎使用：须用未导出类型作 key（如 type userIDKey struct{}），禁用字符串 key；取值必须用双返回值断言（v, ok := ctx.Value(k).(T)）；HTTP 中间件需调用 r.WithContext() 传递新 ctx；多值应打包进不可变结构体单次注入；业务参数不得依赖 Value，须显式传参。
context.Value 不该被禁用，但 90% 的误用都源于 key 设计、值类型和调用链断裂 —— 它不是不能用，是必须按规则用。
为什么字符串 key 必然导致冲突和覆盖
写 context.WithValue(ctx, "user_id", 123) 看似简单，实际埋下严重隐患：两个不同包里各自定义相同字面量 "user_id"，它们在 Go 的 == 比较中完全等价，值会互相覆盖，且编译器零提示。更糟的是，这种覆盖发生在运行时，日志里只看到 panic: interface conversion: interface {} is nil, not int，根本查不到源头。
必须用未导出类型作 key：
- 定义
type userIDKey struct{}（推荐空 struct，零内存开销） - 全局唯一变量：
var UserIDKey = userIDKey{}，所有地方复用它 - 禁用
type ctxKey string这类写法——哪怕加了前缀，只要类型不同，ctx.Value(k1)就永远拿不到ctx.Value(k2)
取值 panic 的真实原因和安全写法
直接写 ctx.Value(UserIDKey).(int) 是最常见 panic 来源。类型断言失败或 key 不存在时返回 nil，强转就崩，尤其在中间件或 goroutine 里，错误堆栈极难定位。
正确姿势只有这一种：
- 永远用双返回值形式：
v, ok := ctx.Value(UserIDKey).(int)，再判断ok - 若值可能是指针或接口，断言前先确认
v != nil - 强烈建议封装工具函数，如
func UserIDFromCtx(ctx context.Context) (int, bool)，内部统一做非空 + 类型检查
HTTP 中间件里值“传不下去”的根本原因
你在中间件里写了 ctx := context.WithValue(r.Context(), UserIDKey, uid)，但 handler 里 ctx.Value(UserIDKey) 还是 nil——因为 r.Context() 是只读副本，改完不绑定回请求对象，下游根本收不到。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
必须显式调用 r = r.WithContext(ctx) 才能让后续 handler 拿到新 ctx：
- 中间件末尾加一句：
next.ServeHTTP(w, r)前，先r = r.WithContext(newCtx) - 别在 handler 里自己 new
context.Background()替换掉原始 request ctx - 多个中间件设同一 key 时，下游应复用上游已设的值，避免重复覆盖
传多个值时别链式 WithValue，性能和可维护性都垮
连续三次 context.WithValue(ctx, k1, v1) → context.WithValue(ctx, k2, v2) → context.WithValue(ctx, k3, v3)，会生成三层嵌套的 valueCtx，查找 key 需遍历整条链，性能线性下降；调试时也看不出哪些值在哪一层注入。
正确做法是打包一次：
- 定义不可变结构体：
type reqMeta struct{ ID string; Lang string; TenantID int64 } - 单次注入：
ctx = context.WithValue(ctx, metaKey{}, reqMeta{ID: "req-123", Lang: "zh-CN"}) - 禁止传指针或可变 map；若需“修改”，必须 COW（Copy-on-Write）重建新 struct 实例
真正容易被忽略的点是：Value 只承载请求生命周期内全局有效、所有中间层都可能需要的元数据；具体业务逻辑需要的参数，必须显式声明为函数参数 —— 这条边界一旦模糊，代码就会滑向隐式依赖和难以测试的泥潭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
