Context传值仅用于透传请求级只读元数据（如traceID、userID），非业务参数；string key因类型无法隔离致覆盖冲突，须用未导出私有类型（如type userIDKey struct{}）；传指针引发data race；中间件需r=r.WithContext(newCtx)才能向下传递；取值必须用v, ok := ctx.Value(k).(t)双返回值断言。
Context 传值不是为了跨层传业务参数，而是为了解决“请求链路中无法改函数签名时，透传少量只读元数据”的问题。滥用会导致 panic、data race 和链路断裂。
为什么 string 类型的 key 一定会出问题
你写 context.WithValue(ctx, "user_id", 123)，别人在另一个包里也写 context.WithValue(ctx, "user_id", "admin")，两个值会互相覆盖——Go 的 Value 查找靠 key == key 判断，而字符串字面量虽内容相同，类型却无法隔离。
- 必须定义未导出的私有类型，例如
type userIDKey struct{}，再声明全局变量var UserIDKey = userIDKey{} - 千万别在不同文件里各自定义
type Key string—— 它们类型不等价，ctx.Value(k1)永远拿不到ctx.Value(k2) - 用
struct{}或空interface{}也不行：前者不可比较（panic: context value not comparable），后者无法保证唯一性
传结构体指针为什么危险
Context.Value 设计初衷是存 requestID、traceID 这类轻量、只读、生命周期与请求一致的元数据。传 *User 指针看似方便，实则埋下并发隐患：
- 多个 goroutine 同时读写该结构体字段，触发 data race（go run -race 可复现）
- 下游协程修改了字段，上游无感知，日志和调试时发现值“莫名其妙变了”
- 若结构体含
map、slice、func等不可比较字段，WithValue调用直接 panic - 真正需要传递对象时，应转为不可变结构体（所有字段可比较 + 无指针字段），或打包为只读接口（如
interface{ GetID() string }）
HTTP 中间件里值“传不下去”的真实原因
你在中间件里调了 context.WithValue(r.Context(), key, val)，但 handler 里 ctx.Value(key) 还是 nil —— 因为 r.Context() 是只读副本，改完不绑定回请求对象，下游根本收不到。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
r = r.WithContext(newCtx)替换原 request 的 context，否则 chi、gin、echo 等框架的c.Request都读不到 - 别在中间件里反复
WithValue覆盖同个 key，下游应复用上游已设的值；覆盖会导致取到的是最近一次 set 的值，而非最初来源 - goroutine 启动时也要显式传入 context：
go doWork(ctx)，否则新 goroutine 拿到的是context.Background()，TraceID 就断了
取值时 panic 的典型写法和安全姿势
写 v := ctx.Value(UserIDKey).(string) 是最常见 panic 来源：类型断言失败直接崩溃，错误常藏在中间件或异步 goroutine 里，日志只显示 panic: interface conversion: interface {} is nil, not string。
- 永远用双返回值形式：
v, ok := ctx.Value(UserIDKey).(string)，再判断ok - 建议封装工具函数，如
func UserIDFromCtx(ctx context.Context) (string, bool)，内部做类型检查和零值过滤 - 如果值可能为
nil（比如指针或接口），断言前先确认v != nil - 别在循环里反复调用
ctx.Value—— 语义上表示“这个值不该频繁查”，应提前提取到局部变量
最易被忽略的一点：WithValue 是链表式查找，每层嵌套都增加 O(n) 开销。中间件套娃超过 5 层后，高频路径（如日志打点）的性能损耗会明显上升；此时应考虑提前构造好所需 context，或把多个元数据打包进一个不可变结构体单次注入。
