context.withvalue仅用于传递请求级不可变元数据，90%问题源于key类型冲突、未传递新ctx或误作函数参数；必须用未导出struct作key、双返回值取值、避免传指针/map/大结构体。
直接说结论：context.WithValue 能传值，但 90% 的 panic 和 nil 返回都源于 key 类型冲突、漏传新 ctx、或误当函数参数用——它不是万能槽，而是只该装请求级元数据的“标签袋”。
为什么 ctx.Value(key) 总是返回 nil
根本不是 API 写错了，而是你没意识到：context.WithValue 不修改原 ctx，它返回一个全新 context。旧变量仍指向老实例，下游调用的还是那个没改过的 ctx。
- 错误写法：
ctx = context.WithValue(ctx, key, val)后没把新ctx传给下一个函数，下游仍在用旧ctx - HTTP 中间件里更常见：调了
context.WithValue(r.Context(), key, val)，但没执行r = r.WithContext(newCtx)，handler 拿到的仍是原始 request context - Gin 用户注意：
c.Request.Context()是只读副本，必须写成c.Request = c.Request.WithContext(newCtx)
用什么做 key 才不会撞车
字符串字面量如 "user_id" 看似方便，实则危险——不同包里一模一样的字符串 key 会互相覆盖，编译器零提示，运行时才出问题。
- 正确做法：定义未导出空 struct 类型，例如
type userIDKey struct{}，再声明全局变量var UserIDKey = userIDKey{} - 禁止写法：
var UserKey = "user_id"（本质仍是 string）、type Key string在多个文件里重复定义（类型不等价） - 小技巧：key 类型不必带字段，
struct{}足够；导出与否看使用范围，跨包共享就导出变量名，但类型本身保持未导出
ctx.Value(key) 取值时为啥 panic
最常见原因是跳过类型断言安全检查：ctx.Value(UserIDKey).(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 != "" } - 别传指针、map、slice 或大结构体——不仅易引发 data race，
Value查找本身是链表遍历，性能随嵌套层数线性下降
哪些值算“安全”，哪些绝对不能塞进 context.WithValue
它不是共享内存池，也不是函数参数替代品。Go 官方明确说：只用于传递请求生命周期内的**不可变元数据**。
- ✅ 安全：小整数、
string、time.Time、bool、轻量不可变 struct（如type ReqMeta struct{ ID, Lang string }） - ❌ 危险：
*sql.Tx、map[string]string、[]byte、结构体指针、配置对象——既破坏不可变契约，又极易触发并发竞争 - ⚠️ 多值场景：别链式调用三次
WithValue，应打包成单个不可变 struct 注入，避免创建多层valueCtx嵌套 - 关键边界：业务逻辑强依赖的参数（如
db *sql.DB、userID string）必须显式作为函数参数，而非塞进 context
真正容易被忽略的点在于：WithValue 的 key 类型和值类型必须从一开始就约定好，且所有参与方（中间件、handler、异步 goroutine）都要复用同一套 key 定义和取值逻辑——漏掉一处类型断言或绑定步骤，整个链路就断了，而且没有编译错误提醒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
