Go微服务中不存在全局链路ID注入函数，唯一可靠方式是手动在HTTP/gRPC/异步入口处用context.WithValue注入，并全程显式传递context；漏传任意一环即导致链路断裂。
Go 微服务里不存在“全局链路 ID 注入函数”这种东西——所谓“全局”，只是误把入口处一次注入、后续靠显式传递营造的假象。真正能透传 TraceID 的唯一载体是 context.Context，且必须手动 extract + inject，漏掉任意一环，链路就断。
为什么不能写一个 InjectTraceID(ctx, tid) 自动生效
Go 没有线程局部存储（TLS），goroutine 之间不共享内存，context.WithValue 构造的新 ctx 不会自动扩散到所有子协程或下游调用中。
- 定义
func InjectTraceID(ctx context.Context, tid string) {}但没把返回的新ctx传下去，下游仍用context.Background()或旧ctx，取值就是nil - 写
go doWork()而不是go doWork(ctx)，新 goroutine 拿到的是空context.Background() - 用
runtime.GoID()查全局 map 存 trace_id —— goroutine 复用后查错、GC 压力大、跨调度不可靠，生产环境禁用
真正有效的注入只发生在三处入口
“注入”本质是构造带值的新 ctx 并确保它被后续逻辑使用，只能在以下位置做：
-
HTTP 入口：中间件中从
r.Header.Get("traceparent")解析（优先），fallback 到X-Trace-ID或X-Request-ID；用context.WithValue(r.Context(), traceKey{}, tid)注入，再调r.WithContext(newCtx) -
gRPC 入口：服务端
UnaryServerInterceptor中用metadata.FromIncomingContext(ctx)提取，再注入新ctx；客户端发起调用前，用metadata.Pairs("x-trace-id", tid)构造metadata.MD，再通过grpc.MetadataCarrier注入 -
异步任务起点：如 Kafka 消费，从消息 payload 解析 trace_id，用
context.WithValue(context.Background(), traceKey{}, tid)构造初始ctx
注意：traceKey{} 必须是未导出私有 struct 类型（如 type traceKey struct{}），绝不能用 "trace_id" 字符串字面量，否则跨包 key 冲突概率极高。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
HTTP/gRPC 客户端透传必须手动 extract + inject
http.Client 和 grpc.ClientConn 都不会自动读取当前 ctx 里的 trace_id 并写入 header/metadata，你得自己干：
- 从
ctx.Value(traceKey{})取值，若为空可 fallback 生成新 ID（视业务容忍度） - HTTP 请求：写入标准字段，如
req.Header.Set("traceparent", "00-" + tid + "-" + spanID + "-01")；推荐用otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header))，避免手拼格式出错 - gRPC 请求：用
grpc.InjectMetadata(ctx, md)或更常见的grpc.MetadataCarrier方式注入metadata.MD - 数据库调用必须用
db.QueryContext(ctx, ...)，不能用db.Query(...)
goroutine 启动时最容易丢 TraceID
这是线上链路断裂最常见原因——go fn() 不继承父 ctx，新协程拿到的是 context.Background()。
- 错误写法：
go processOrder()→processOrder内部调ctx.Value(traceKey{})返回nil - 正确写法：
go processOrder(ctx)，且函数签名必须是func processOrder(ctx context.Context) - 如果启动多个 goroutine，每个都得传入当前请求的
ctx，不能共用闭包变量或全局 ctx 实例 - 日志库（如 zap）要桥接
ctx，不能靠log.Printf("trace_id=%s", getTraceID())这种无参封装——内部若依赖 runtime.GoID() 查 map，同样不可靠
复杂点不在“怎么做”，而在“每处都做对”：HTTP 入口、goroutine 启动、DB 查询、gRPC 调用、异步消费……只要有一处漏传或误用 context.Background()，整条链路就断成两截。
