context仅传递取消信号、超时控制及少量元数据（如traceid），业务数据应走函数参数或结构体；withvalue的key须为自定义类型；http handler优先用withtimeout并defer cancel；goroutine中defer cancel会失效，应传入外部ctx或显式调用cancel。
Context 里不该放业务数据
很多人一看到 context.WithValue 就立刻往里塞用户 ID、Token、请求参数，结果调试时发现值丢了、类型断言 panic、甚至 goroutine 泄漏。这不是 Context 的设计本意——它只负责传递取消信号、超时控制和少量**元数据**（比如 traceID、spanID），不是通用的 request-scoped storage。
- 业务字段该走函数参数或结构体字段，清晰、可测试、不隐式
-
context.WithValue只适合传真正跨多层调用、又不便改函数签名的“上下文线索”，比如request_id或trace_id - 所有
context.WithValue的 key 必须是自定义类型（不能用String），否则不同包之间容易键冲突 - 示例中常见错误：
ctx = context.WithValue(ctx, "user_id", 123)→ 应写成type userIDKey Struct{}+ctx = context.WithValue(ctx, userIDKey{}, 123)
全链路 traceID 怎么安全注入到 Context
traceID 是最典型的 Context 元数据使用场景，但直接从 HTTP header 解析后硬塞进 root context 容易出错：没校验格式、没做长度截断、没统一大小写，下游服务日志对不上。
- 务必在入口处（如 HTTP middleware）一次性解析并标准化 traceID：
strings.TrimSpace(strings.ToLower(r.Header.Get("X-Trace-ID"))) - 用固定 key 注入，例如定义
var traceIDKey = struct{}{}，避免字符串拼写错误 - 下游服务不要自己生成 traceID，除非当前 ctx 没有（即非透传请求），此时才调用
uuid.NewString()创建新 trace - 注意：gRPC 默认用
grpc-trace-binheader，格式是二进制 W3C TraceContext，需用otel.GetTextMapPropagator().Extract()（如果用 OpenTelemetry）
WithCancel / WithTimeout 哪个更适合 HTTP handler
HTTP handler 几乎总是该用 context.WithTimeout，而不是 context.WithCancel 手动控制。手动 cancel 容易漏调用、goroutine 持有 ctx 不释放、或者 cancel 太早导致中间件还没写完 response 就中断。
- 标准写法：
ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)，然后defer cancel() - 别在 handler 里用
context.WithCancel(context.background())—— 这会切断父 context 的取消链，上游超时或中断无法通知到你 - 数据库查询、HTTP client 调用必须显式传入这个带 timeout 的 ctx，否则可能永远卡住
- 注意：
http.Server.ReadTimeout和WriteTimeout是连接级的，不影响 handler 内部逻辑执行时间，所以 handler 自己的 ctx timeout 不可省
为什么 defer cancel() 在 goroutine 里会失效
这是线上最隐蔽的 Context 泄漏来源之一：把 ctx, cancel := context.WithTimeout(...) 放在 goroutine 里，再 defer cancel()，结果 cancel 永远不执行，ctx 一直存活，内存和 goroutine 都涨。
立即学习“go语言免费学习笔记（深入）”；
- 原因：
defer只在函数 return 时触发，而 goroutine 是独立函数，如果它没退出，defer 就不会跑 - 正确做法：要么不用 defer，在 goroutine 结束前明确调用
cancel()；要么用context.WithCancelCause（Go 1.21+）配合 select 监听 done channel - 更稳妥的是——别在 goroutine 里新建带 cancel 的子 context，而是把外部已有的 ctx 传进去，由上层统一控制生命周期
- 验证方式：pprof 查看
runtime.goroutines数量持续上涨，且堆栈里大量出现context.(*cancelCtx).cancel未完成状态
事情说清了就结束。Context 的复杂性不在 API，而在谁创建、谁取消、谁持有、谁透传——这四个角色一旦错位，问题就藏得深、查得慢。