context.withvalue 返回新 context，必须手动传递下游；key 应用未导出 struct 类型防冲突；取值须用双返回值断言防 panic；仅传轻量不可变元数据，禁传指针、map 等。
context.WithValue 能传值，但 90% 的 nil 返回和 panic 都是因为 key 类型冲突、没把新 ctx 传下去、或者误以为它会原地修改旧 ctx。
ctx.Value(key) 总是返回 nil 怎么办
根本不是 API 写错了，而是你调用了 context.WithValue(ctx, key, val) 后，没把返回的新 ctx 传给下游函数——旧变量仍指向原始 context，下游调用 ctx.Value(key) 当然得到 nil。
- HTTP 中间件里尤其常见：写了
ctx = context.WithValue(r.Context(), key, val)，但忘了r = r.WithContext(ctx)，后续 handler 拿到的还是原始 request context - Gin 用户注意：
c.Request.Context()是只读副本，必须显式写成c.Request = c.Request.WithContext(newCtx) - 函数链中漏传一个环节（比如 A → B → C，B 改了 ctx 却传了旧 ctx 给 C），整条链就断了
用什么做 key 才不会撞车
别用字符串字面量，比如 "user_id" 或 var UserKey = "user_id"——不同包里一模一样的字符串 key 会互相覆盖，编译器不报错，运行时静默丢值。
- 正确做法：定义未导出空 struct 类型，例如
type userIDKey struct{}，再声明全局变量var UserIDKey = userIDKey{} - 禁止写法：
type Key string在多个文件重复定义（类型不等价）、var UserKey interface{}（不可比较，Value()直接 panic） - key 类型不必带字段，
struct{}就够；是否导出看使用范围：跨包共享就导出变量名，类型本身保持未导出
取值时为啥 panic
ctx.Value(key).(string) 这种单返回值强制类型断言，一旦值不存在或类型不符，直接 panic，而且堆栈常藏在中间件或 goroutine 里难定位。
- 必须用双返回值形式：
v, ok := ctx.Value(UserIDKey).(string)，再判断ok - 如果值可能为
nil（比如指针或接口），加一层非空判断：if v != nil && ok { ... } - 强烈建议封装成工具函数，例如：
func GetUserID(ctx context.Context) (string, bool) { v, ok := ctx.Value(UserIDKey).(string); return v, ok && v != "" }
WithValue 传什么、不传什么
它只该装请求级元数据，不是万能参数槽。传错东西不仅逻辑错乱，还容易引发 data race 或性能问题。
- 允许传：轻量、不可变、可比较的值，比如
string、int、struct{}、小的只读结构体 - 禁止传：
[]byte、map、slice、指针、大结构体——Value()查找是链表遍历，性能随嵌套层数线性下降；传指针或 map 还可能引发并发写 panic - 业务参数别塞进去：用户 ID 可以，但订单详情、配置对象、数据库连接池这些不该走
WithValue，该走函数参数或依赖注入
最易被忽略的一点：context 不是“自动传播”的，它完全依赖你手动传递。哪怕只漏掉一次 ctx 参数更新，整条链路上的元数据就消失了，且没有任何编译期提示。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
