context.WithValue 的 key 必须是未导出空结构体（如 type userIDKey struct{}），因 string 或 int 作 key 会丧失类型安全与命名空间隔离，导致跨包键冲突、值被覆盖或断言 panic；取值须封装函数统一判 ok，HTTP 中间件需显式 r = r.WithContext(newCtx) 才能透传，且 Context 仅应传递轻量只读元数据，业务数据应走函数参数。
Context 在 Go 里不是“学会怎么传”，而是“知道该不该传、传什么、谁负责传”——传错、多传、漏传，比不传更危险。
context.WithValue 的 key 为什么必须是未导出 struct{}
用 string 或 int 当 key，等于放弃类型安全和命名空间隔离。不同包都定义 "user_id"，ctx.Value("user_id") 可能拿到别人塞的值，且编译器完全不报错。
- ✅ 正确做法：定义私有空结构体，如
type userIDKey struct{}，再用userIDKey{}实例作 key - ❌ 错误写法：
ctx = context.WithValue(ctx, "user_id", 123)—— 全局字符串易冲突，取值时断言失败直接 panic - 取值必须封装函数，统一做
ok判断：例如func UserIDFrom(ctx context.Context) (int64, bool)，不能裸调ctx.Value(userIDKey{}).(int64)
HTTP 中间件里 ctx 更新后必须重赋值给 *http.Request
r.Context() 返回的是只读副本，修改它不会影响后续 handler。常见错误是调用 context.WithValue(r.Context(), ...) 后没把新 ctx 写回 request，导致下游拿不到。
- ✅ 必须写：
r = r.WithContext(newCtx)，再调next.ServeHTTP(w, r) - ❌ 漏掉这步，
next里的r.Context().Value(...)仍是原始 ctx，值为空或旧值 - 中间件链越长，漏写风险越高；建议所有中间件开头统一加
ctx := r.Context()，结尾统一r = r.WithContext(ctx)
业务数据别塞 Context，显式参数才是正解
context.WithValue 不是状态容器，它的设计目标仅限于传递请求级、只读、轻量元数据（如 traceID、tenantID、lang）。塞业务对象会引发三类问题：
立即学习“go语言免费学习笔记（深入）”；
- 内存泄漏：Context 生命周期常覆盖整个请求，
*Order或map[string]interface{}无法及时 GC - 隐性耦合：函数签名看不出依赖什么数据，调用方无法感知，测试时还得手动构造完整 ctx 链
- 类型失控：多个地方对同一 key 做不同类型的断言（
.(string)vs.(*User)），运行时 panic - 真正该传的业务参数，就老老实实放在函数签名里：
func ProcessOrder(ctx context.Context, orderID string, timeout time.Duration)
goroutine 启动时 ctx 必须显式传入，且 Done() 监听后要查 Err()
在 goroutine 里直接用 context.Background() 或闭包捕获外层 ctx，会导致取消信号中断。更隐蔽的问题是：只监听 不够，必须紧接着调 <code>ctx.Err() 判断原因。
- ✅ 正确模式：
go func(ctx context.Context) { ... select { case - ❌ 错误写法：
case -
WithTimeout创建的cancel函数必须调用（哪怕没超时），否则内部*time.Timer泄漏；惯用写法是defer cancel()，但要确保 defer 在 goroutine 内部，而非外层函数
最常被忽略的一点：Context 传递不是技术问题，是契约问题——每个函数签名里要不要带 ctx context.Context，取决于它是否可能触发 I/O 或启动子 goroutine；一旦加了，就必须从上到下每一层都显式透传，中间任何一层“省事不传”，整条链路的超时和取消就失效了。
