context 传值仅适用于不可变元数据（如 trace id、auth.user），而非业务数据；核心能力是 deadline/cancel 控制子任务生命周期；http handler 必须用 r.context() 而非 context.background()；trace id 需入口注入并全程透传。
Context 传值不是为存业务数据设计的
用 context.WithValue 塞用户 ID、请求 ID 或配置项，短期能跑通，但很快会失控。Go 官方文档明确说它只适合传递“请求作用域的、不可变的元数据”，比如 trace ID、认证主体（auth.User）、超时控制信号——不是用来替代函数参数或结构体字段的。
常见错误现象：context.Value 返回 nil 却没做类型断言检查，panic；或者多层中间件反复 WithValue 覆盖同个 key，下游取到的值和预期不符。
- 永远用自定义类型作 key（
type ctxKey string），别用string字面量——避免跨包 key 冲突 - 值必须是线程安全的；如果传指针，确保底层数据不会被并发修改
- 不传大对象（如整个 request struct），Context 是链式传递的，拷贝开销小，但滥用会模糊数据流向
Deadline 和 Cancel 是 Context 的真正核心能力
90% 的 Context 误用，都源于只盯着 WithValue，却忽略 WithTimeout、WithCancel 才是它存在的根本理由：统一控制子任务生命周期。
使用场景：HTTP handler 启动 goroutine 调用下游服务，主请求超时了，必须让所有子 goroutine 立刻退出，而不是等它们自己结束。
立即学习“go语言免费学习笔记（深入）”；
-
context.WithTimeout(parent, 5*time.Second)自动创建 timer 并在到期后调用cancel() - 手动调用
cancel()不仅终止计时器，还会关闭关联的Done()channel，所有监听它的 goroutine 都能立刻感知 - 注意：cancel 函数只能调用一次；重复调用会 panic，建议用
defer cancel()+ 显式作用域控制
HTTP Server 中 context.Background() 是个危险起点
写 handler 时直接用 context.Background() 启动 goroutine，等于把该 goroutine 从整个请求生命周期里“摘出去”了——它既不响应客户端断连，也不受路由层设置的超时约束。
正确做法永远是用 r.Context()（*http.Request 提供的）作为起点：
- HTTP/2 流复用下，
r.Context()会随单个请求流自动取消，而Background()永远存活 - 中间件（如 auth、rate limit）注入的数据也只存在于
r.Context()链中 - 若需延长生命周期（如异步日志上报），应显式派生带独立 timeout 的子 context，而非退化到 Background
链路追踪 ID 必须在入口处注入并透传
想实现跨服务 trace，关键不是“怎么打日志”，而是“如何让每个环节都拿到同一个 trace ID”。这要求你在最外层（如 HTTP 入口）就生成或提取它，并通过 Context 一路向下传，中间绝不丢失。
常见错误：中间件提取了 X-Trace-ID header，但只存进 local var，没塞进 context；或者调用下游 HTTP client 时没把当前 context 传进去，导致下游无法继续透传。
- 入口处用
ctx = context.WithValue(r.Context(), traceKey, traceID)注入 - 调用下游时，用
http.NewRequestWithContext(ctx, ...)，否则 client 默认用context.Background() - gRPC 场景同理：
grpc.DialContext(ctx, ...)和client.Method(ctx, req)都要传 ctx
复杂点在于：一旦某层忘了传 context，整条链就断了。没有银弹，只能靠代码审查 + 静态检查工具（如 go vet -shadow 辅助发现未使用的 ctx 变量）盯住每一处调用点。
