关键在于全程显式透传：HTTP需手动设traceparent/X-Request-ID头，gRPC须用metadata.Pairs注入traceparent，goroutine必须显式传ctx，日志和DB调用均需从ctx提取traceID注入。
Go 服务中请求链路 ID（trace ID）要真正透传到下游 HTTP/gRPC 服务，关键不是生成 ID，而是确保它在每个中间环节——包括 http.Client、context.Context、HTTP header、gRPC metadata——都不被丢弃或覆盖。
HTTP 请求发起时必须显式注入 trace ID 到 header
Go 的 http.Client 不会自动读取 context 中的 trace ID，也不会自动写入 X-Request-ID 或 traceparent。你得手动从 ctx 取值、构造 header、再塞进 http.Request。
- 别依赖中间件“全局注入”：中间件只能处理入站请求，出站请求必须在每次调用
http.NewRequestWithContext后手动设置 - 推荐统一用
traceparent（W3C 标准），格式为"00-{trace-id}-{span-id}-01"，其中trace-id和span-id都是 32 位小写十六进制字符串 - 如果下游是旧系统，可同时设
X-Request-ID，但注意它不携带 span 层级信息，仅作 fallback
示例：
req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/v1/user", nil)
traceID := getTraceIDFromCtx(ctx) // 你自己实现的提取函数
spanID := generateSpanID()
req.Header.Set("traceparent", fmt.Sprintf("00-%s-%s-01", traceID, spanID))
req.Header.Set("X-Request-ID", traceID)
gRPC 客户端调用必须通过 metadata 透传
gRPC 的 context 透传机制和 HTTP 完全不同：它依赖 metadata.MD，且必须在每次 Invoke 或 NewStream 前显式附加，context.WithValue 本身不会自动转成 wire-level metadata。
- 不要只在 context 里存 trace ID 然后期望 gRPC 自动发出去——它不会
- 必须用
metadata.Pairs("traceparent", val)构造metadata.MD，再用grpc.MetadataCarrier注入到 context - 若使用拦截器（interceptor），确保拦截器执行顺序正确：client interceptor 必须在实际 RPC 调用前完成 metadata 注入
示例（无拦截器场景）：
md := metadata.Pairs(
"traceparent", fmt.Sprintf("00-%s-%s-01", traceID, spanID),
"X-Request-ID", traceID,
)
ctx = metadata.NewOutgoingContext(ctx, md)
resp, err := client.GetUser(ctx, &pb.GetUserRequest{Id: "123"})
中间件和 goroutine 分叉时容易丢失 trace ID
Go 的 context.WithValue 是浅拷贝，但一旦启动新 goroutine 且没显式传入带 trace 的 context，或者用了 context.Background() / context.TODO()，trace ID 就彻底断了。
- 所有异步操作（如
go func() { ... }()）必须显式接收并使用原始ctx，不能闭包捕获外部变量后另起 context - 数据库查询、日志打点、缓存操作等，只要涉及跨组件，都应从当前
ctx提取 trace ID 并写入日志字段或 span tag - 避免在 handler 内部新建
context.WithTimeout(context.Background(), ...)——这直接切断了链路
不要信任第三方库的“自动透传”能力
像 sqlx、redis-go、ent 这类库本身不感知 trace context；即使用了 OpenTelemetry 的 instrumentation，也依赖你正确初始化 otel.Tracer 并把 context 传到底层调用点。
- OpenTelemetry 的
Tracer.Start(ctx, ...)必须传入含 trace ID 的 context，否则会生成全新 trace - logrus/zap 日志库需配合
WithValues("trace_id", getTraceIDFromCtx(ctx))手动注入，不然日志里看不到 trace ID - 某些 SDK（如 AWS SDK for Go v2）支持
middleware注入 header，但默认关闭，需显式配置AddMiddleware
最常被忽略的一点：HTTP server 的 http.ServeMux 或 gin.Engine 默认不解析 traceparent header，你需要自己写中间件提取并写入 context——否则下游拿到的就是空 trace ID。
