go微服务中context.context是唯一可靠透传traceid的载体，因无tls和隐式上下文传播机制，“全局注入函数”不可行；有效注入仅发生在http/grpc入口、异步任务起点三处，且需手动extract+inject透传至下游。
Go 微服务里，context.Context 是唯一能可靠透传 TraceID 的载体，没有“全局注入函数”这种东西——所谓“注入”，本质是每次调用前手动构造带值的新 Context，不是靠某个函数自动塞进所有 goroutine。
为什么不能写一个“全局注入函数”自动透传
Go 没有线程局部存储（TLS），goroutine 之间不共享内存，也没有隐式上下文传播机制。所谓“全局注入”，如果指类似 Java MDC 那种无需显式传参就能在任意位置取到 trace_id 的能力，在 Go 里要么靠 unsafe 黑魔法（生产环境禁用），要么用全局 map + goroutine ID 做映射（竞态、GC 压力大、无法跨 goroutine 传递），实际项目中已被反复验证为不可靠。
常见错误现象：
- 定义一个
func InjectTraceID(ctx context.Context, tid string) {}，但没在后续调用链中真正把新 ctx 传下去，下游仍用context.Background()或旧 ctx - 在 goroutine 启动时漏掉
go fn(ctx)，写成go fn()，导致新协程里ctx.Value()返回nil - 用
log.Printf("trace_id=%s", getTraceID())这类无 ctx 参数的封装，内部靠 runtime.GoID() 查 map —— 一旦 goroutine 复用或调度变化，查不到或查错
真正有效的“注入”只发生在三处关键节点
所谓“注入”，是指把 trace_id 显式塞进 context.WithValue() 构造的新 Context，并确保它被下游使用。必须且只能在以下位置做：
-
HTTP 入口：中间件中从
r.Header.Get("X-Trace-ID")或traceparent解析，再调用context.WithValue(r.Context(), traceKey{}, tid) -
gRPC 入口：UnaryServerInterceptor 中用
metadata.FromIncomingContext(ctx)提取，再注入新 ctx；客户端用metadata.Pairs("trace-id", tid)+grpc.MetadataCarrier -
异步任务起点：比如消息队列消费，从消息 payload 解析
trace_id，再用context.WithValue(context.Background(), traceKey{}, tid)构造初始 ctx
注意：traceKey{} 必须是自定义类型（如 type traceKey struct{}），不能用字符串字面量，否则不同包之间 key 冲突概率极高。
HTTP 客户端透传必须手动 extract + inject
Go 的 http.Client 不会自动读取当前 ctx 里的 trace_id 并写入请求头，你得自己干：
- 从 ctx 取值：
if tid, ok := ctx.Value(traceKey{}).(string); ok - 构造请求时带上：
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil) - 再写 header：
req.Header.Set("X-Trace-ID", tid)或 OpenTelemetry 标准格式req.Header.Set("traceparent", "00-"+tid+"-"+spanID+"-01") - 推荐封装成
DoWithTrace(ctx, req)工具函数，避免每个 HTTP 调用都重复判断
漏掉其中任何一步，下游服务收到的请求就没有 trace_id，链路就断了——这不是配置问题，是代码逻辑缺失。
日志库必须主动读取 context，不能指望“自动”
zap、logrus、zerolog 都不读 context.Context，所谓“自动注入”全是封装出来的假象：
- 每次打日志前，必须从当前 goroutine 的 ctx 中取：
if tid, ok := ctx.Value(traceKey{}).(string); ok { logger = logger.With(zap.String("trace_id", tid)) } - 更稳妥的做法是封装
Logger.WithContext(ctx)方法，返回一个已携带trace_id字段的新 logger 实例 - 特别注意：goroutine 内部的日志，ctx 必须是启动时传入的那个，不能在 goroutine 里直接用
context.Background()或未注入的 ctx
最容易被忽略的是：HTTP handler 里中间件注入了 trace_id，但 service 层调用 DB 时启了个 goroutine 去发通知，那个 goroutine 没传 ctx，日志就丢了——这和“注入函数”无关，只和你是否显式传递有关。
