go的context.context不跨进程，需通过http头（如traceparent）或grpc metadata手动透传traceid等元数据；key须为自定义类型，value仅存不可变轻量数据；异步任务应剥离取消信号，避免被请求生命周期绑架。
异构微服务间无法靠 context.WithValue 直接透传上下文
Go 的 context.Context 本身不跨进程——它只在单个 Go 进程内有效。你在 A 服务里用 context.WithValue 塞了 traceID 或 userID，B 服务收不到，除非你手动把它编码进网络协议层。这不是 bug，是设计使然：Context 不是序列化容器，而是运行时协程通信机制。
常见错误是以为“只要上游塞了、下游 req.Context() 取一下就能拿到”，结果链路追踪断在第一个 HTTP 跳转点，日志里 traceID 全是空字符串。
- HTTP 场景下，必须通过标准头（如
traceparent）传递，不能用X-Trace-ID这类自定义头 - gRPC 场景下，必须用
metadata.MD封装，再由拦截器注入/提取，context.Value不会自动随请求序列化 - 跨语言（比如 Go ↔ Java/Python）时，仅靠 Go 的 Context 机制完全失效，必须依赖 W3C TraceContext 或 B3 等通用传播协议
定制模块必须封装 OpenTelemetry Propagator 而非自己拼 header
自己手写 req.Header.Set("traceparent", "00-"+tid+"-"+sid+"-01") 看似能跑通，但会漏掉采样标志、baggage、trace-flags 等关键字段，下游 SDK 无法重建合法 span，链路变成“断点式”而非“连续式”。
正确做法是复用 OpenTelemetry 提供的传播器（Propagator），它已适配所有主流格式和边界 case：
- 客户端注入：
otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header)) - 服务端解析：
otel.GetTextMapPropagator().Extract(ctx, propagation.HeaderCarrier(r.Header)) - 若需兼容 Jaeger/Zapkin，注册复合 propagator：
propagation.NewCompositeTextMapPropagator(propagation.B3{}, propagation.TraceContext{}) - 别自己实现
HeaderCarrier—— 它只是个包装 interface，直接用官方提供的即可
Go 模块中 key 类型必须自定义，且 Value 仅存不可变元数据
即使你在模块里统一用了 context.WithValue，如果 key 是字符串（如 "user_id"），不同中间件或依赖库可能重复使用相同 key，导致值被覆盖或类型断言失败（panic: interface conversion: interface {} is nil）。
安全做法是把 key 定义为私有类型，并导出唯一实例：
type userIDKey string
const userIDKeyCtx userIDKey = "user_id"
// 使用时
ctx = context.WithValue(ctx, userIDKeyCtx, "12345")
// 取值时
if uid, ok := ctx.Value(userIDKeyCtx).(string); ok {
// 安全
}
- 业务结构体（如
*User、AuthClaims）不要塞进 Context，应作为 handler 参数或中间件返回值显式传递 - 存入的值必须是不可变类型（
string、int、struct{}），避免传指针后被意外修改 - 模块对外暴露的上下文增强函数，应只接受
context.Context和原始*http.Request或grpc.RequestInfo，不暴露内部 key
异步任务和后台 goroutine 必须剥离取消信号
直接把请求的 r.Context() 传给异步 goroutine（比如发消息、写审计日志、刷新缓存），会导致该任务被请求生命周期绑架——HTTP 连接一断，任务就被 cancel，即使它本该继续执行。
定制模块里应提供明确的上下文剥离工具：
- 用
context.WithoutCancel(r.Context())保留Value（如 traceID、userID），丢弃Done通道 - 若需独立超时，再套一层：
context.WithTimeout(context.WithoutCancel(r.Context()), 30*time.Second) - 禁止在 goroutine 外部调用
cancel()—— 模块内部若生成新 cancel 函数，必须确保它只在对应 goroutine 内可控调用 - 对长周期 loop（如轮询、心跳），必须在 select 中监听
ctx.Done()，否则 timer 不释放，引发内存泄漏
真正容易被忽略的是：很多团队写了“透传 context”的模块，却没处理异步场景，结果线上大量后台任务静默失败，监控看不到 error，只看到延迟毛刺或数据不一致。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
