Context本身不能跨进程传递，必须提取关键字段（如traceID、deadline）通过HTTP Header或gRPC metadata序列化透传，下游服务再用其重建本地Context。
Context 本身不能跨进程传递，必须靠序列化+手动重建
Go 的 context.Context 是纯内存结构，不实现 encoding.BinaryMarshaler，也不支持网络传输。所谓“跨进程传递 Context”，实际是把其中关键字段（如 traceID、截止时间、取消意图）抽出来，通过 HTTP header、gRPC metadata 或消息体带过去，下游服务再用这些值新建一个本地 Context。
- HTTP 场景下，
traceID常走traceparent（W3C 标准）、X-Trace-ID或X-Request-ID；超时时间一般不传，由下游按自身 SLA 自行设置context.WithTimeout - gRPC 场景下，用
metadata.MD携带键值对，服务端通过grpc.ServerOption注册拦截器，在ctx中注入元数据 -
context.WithCancel和context.WithDeadline的取消信号无法传递——你不能把一个 channel 或 timer 跨网络发出去；下游只能根据收到的 deadline 时间点，自己调用context.WithDeadline创建新 context - 别试图用
json.Marshal序列化整个context.Context：它会 panic，因为接口类型无法直接序列化，且内部字段（如donechannel）无意义
HTTP 中间件里 traceID 透传失败的三个典型原因
现象是上游写了 X-Trace-ID，下游 ctx.Value(traceKeyKey) 却返回 nil。
- 中间件没把新 context 绑回
*http.Request：只调了context.WithValue(r.Context(), ...)，但漏了r = r.WithContext(newCtx)，后续 handler 拿到的仍是原始 request - key 类型用
string：“trace_id” 在 client 包和 server 包里是两个不同内存地址的字符串，ctx.Value()内部用==比较 key，必然不等 → 必须用未导出 struct 类型，如type traceKey struct{}，全局唯一变量var traceKeyKey = traceKey{} - 下游没在 handler 入口主动从 header 提取并注入：比如用了
chi或gin，但没写中间件或忘了调用c.Request = c.Request.WithContext(...)
goroutine 启动后 traceID 突然为空？不是 Context 没传，是闭包捕获错了
常见写法：go func() { log.Printf("trace: %s", TraceIDFromContext(ctx)) }()，结果日志里 traceID 是空字符串。
- 根本原因：Go 的
go语句不自动继承父 goroutine 的 context；这个ctx变量如果来自外层作用域，可能被循环复用、或指向已过期的 context - 正确做法：显式传参，而不是依赖闭包捕获：
go func(ctx context.Context) { /* ... */ }(r.Context()) - 如果启动多个 goroutine，每个都必须传入同一派生 context（例如带 timeout 的），不能各自 new 或用
context.Background()—— 否则取消信号无法统一控制 - 切忌把
ctx存进 struct 长期持有：会导致取消失效、goroutine 泄漏、值传递断裂
为什么不能把 context.Context 当普通参数塞进 struct
因为 context.Context 不是静态数据容器，而是运行时状态机：它携带动态的取消信号、超时倒计时、value 链表指针。一旦被 struct 长期强引用，就破坏了它的生命周期契约。
立即学习“go语言免费学习笔记（深入）”；
- goroutine 泄漏：子 context 被父 cancel 后，struct 仍持有旧引用，GC 无法回收 timer 和 channel
- 取消失效：struct 初始化时存了 ctx，之后上游调用
cancel()，但 struct 里的 ctx 已不再响应 Done() - 值传递错乱：struct 中的 ctx 没参与
WithValue链，下游读不到最新注入的traceID或user.ID - 正确姿势：每个函数显式接收
ctx context.Context参数，调用下游时传入派生 context；绝不缓存、不嵌入、不跨 goroutine 长期保存
最易被忽略的一点：所有 I/O 操作（http.Client.Do、sql.DB.QueryContext、time.Sleep）必须传入当前 ctx，否则取消和超时机制完全失效——这比 key 类型错误更隐蔽，也更致命。
