context.WithValue 不会自动透传到子 goroutine，需显式传参；HTTP 中须用 r.WithContext 更新请求；key 应私有结构体避免冲突；Value 查找为 O(n) 且有 GC 压力。
context.WithValue 不会自动透传到子 goroutine
协程启动时没显式传入新 context，子 goroutine 拿到的仍是原始或父级 context，ctx.Value(key) 返回 nil。这不是 bug，是设计使然——context 是值类型，不是引用共享状态。
常见错误写法：
ctx = context.WithValue(ctx, userKey, u)
go func() {
// 这里 ctx 是闭包捕获的旧变量，没更新
log.Println(ctx.Value(userKey)) // nil
}()
正确做法必须手动传参：
- 子 goroutine 启动时显式接收新 context：
go worker(newCtx, ...) - 若用
go func(ctx context.Context) { ... }(newCtx)，确保调用时传的是newCtx而非原ctx - 避免在闭包中直接引用外部
ctx变量，除非它已被重新赋值且作用域内可见
HTTP handler 中 r.Context() 是只读副本，必须用 WithContext 更新
中间件里调用 context.WithValue(r.Context(), key, val) 之后，如果不执行 r = r.WithContext(newCtx)，后续 handler 和中间件拿到的 r.Context() 依然是旧 context，值根本不可见。
立即学习“go语言免费学习笔记（深入）”；
典型漏掉的一步：
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
u := parseUser(r.Header)
ctx := context.WithValue(r.Context(), userKey, u)
// ❌ 缺少这行：r = r.WithContext(ctx)
next.ServeHTTP(w, r)
})
}
修复后：
r = r.WithContext(ctx) // ✅ 必须显式绑定回 *http.Request next.ServeHTTP(w, r)
注意：r.WithContext 返回新 *http.Request，原 r 不变，所以必须赋值覆盖。
key 类型冲突导致值被静默覆盖或取不到
用字符串当 key（如 "user_id"）看似简单，但不同包、不同中间件可能各自定义同名 key，结果后注入的值覆盖前一个，或者取值时类型断言失败却无报错。
安全 key 定义方式（必须满足三点）：
- 类型未导出（小写开头），如
type userKey struct{}或type ctxKey string+const userKey ctxKey = "user" - 定义在包内私有 scope，不暴露给其他包使用
- 避免用
int、string等通用类型直接作 key
取值时务必用双返回值断言：
v, ok := ctx.Value(userKey).(User)
if !ok {
// 处理取值失败，比如 log 或 fallback
return
}
单返回值写法 v := ctx.Value(userKey).(User) 在类型不匹配时直接 panic。
WithValue 链过深导致 Value 查找性能下降
每次 context.WithValue 都生成新节点，形成链表结构；查找 ctx.Value(key) 时需遍历整个链，时间复杂度 O(n)。5 层以上嵌套在高频路径（如日志打点、鉴权检查）中可观测到延迟上升。
优化建议：
- 中间件中避免层层套娃：
ctx = context.WithValue(ctx, k1, v1); ctx = context.WithValue(ctx, k2, v2)→ 改为一次注入多个字段的结构体 - 业务逻辑函数不重复调用
WithValue，入口中间件统一提取并注入，后续只读取 - 超轻量元数据（如
traceID、userID）适合放 context；大对象、切片、map 禁止放入，会引发内存泄漏或竞态
真正容易被忽略的是：context 的不可变性意味着每一次 WithValue 都在堆上分配新节点，高频调用本身就有 GC 压力，不只是查找慢。
