Go微服务分布式追踪核心是用OpenTelemetry自动透传Trace ID/Span ID：通过HTTP中间件与gRPC拦截器注入上下文，用context.Context贯穿业务，配置OTLP/Jaeger Exporter导出数据，并关联日志指标实现问题定位。
在 Go 微服务架构中实现分布式追踪，核心是让每次请求携带唯一追踪上下文（Trace ID + Span ID），并在跨服务调用时透传、延续和上报链路数据。主流方案是接入 OpenTelemetry（OTel），它已成云原生追踪事实标准，替代了早期的 Jaeger、Zipkin SDK。
一、用 OpenTelemetry Go SDK 自动注入追踪上下文
无需手动拼接 header，OTel 提供了 HTTP 中间件与 gRPC 拦截器，自动从入站请求提取 traceparent，并为出站请求注入。
- HTTP 服务：用
otelhttp.NewHandler包裹你的 handler，它会解析traceparent并创建 span - gRPC 服务：用
otelgrpc.UnaryServerInterceptor和otelgrpc.UnaryClientInterceptor注册拦截器 - 所有 span 默认继承父上下文，子服务调用时自动带上新 span ID 和同一 trace ID
二、正确传播上下文（Context）贯穿业务逻辑
Go 的 context.Context 是传递追踪信息的载体。关键不是“存 trace id”，而是把带 span 的 context 一路向下传。
- 进来的 HTTP 请求：通过
r.Context()获取已有 span 上下文 - 调用下游服务前：用
otel.GetTextMapPropagator().Inject(ctx, carrier)把 trace context 写入 HTTP header 或 gRPC metadata - 数据库/消息队列操作：使用支持 OTel 的驱动（如
go-sql-driver/mysql配合otelmysql），或手动 wrap 查询函数并新建 child span
三、选择后端并导出追踪数据
OTel 不绑定后端，你只需配置 Exporter。本地开发常用 Jaeger；生产推荐兼容 OTLP 的后端（如 Tempo、Zipkin、Lightstep 或 Honeycomb）。
立即学习“go语言免费学习笔记（深入）”；
- Jaeger 示例：启动
jaeger-all-in-one，Exporter 配置为http://localhost:14250（gRPC endpoint） - OTLP Exporter：最通用，支持协议升级，可直连 Grafana Tempo 或云厂商 APM（如 AWS X-Ray）
- 注意设置采样策略：开发用
AlwaysSample()，生产建议ParentBased(TraceIDRatioBased(0.01))控制上报量
四、可视化与关联：不只是看链路，还要查问题
单靠 UI 展示 span 不够，需打通日志、指标、代码位置，才能快速定位瓶颈。
- 在 span 中添加属性：
span.SetAttributes(attribute.String("db.statement", query))或attribute.Int("http.status_code", statusCode) - 将 trace ID 注入日志（如用
zerolog.With().Str("trace_id", traceID).Logger()），方便在 Loki 或 ELK 中关联日志 - Grafana + Tempo 组合支持 trace-to-metrics 关联，点击慢请求可下钻到对应 CPU/延迟指标
不复杂但容易忽略的是上下文传递完整性——哪怕一个 goroutine 启动时忘了传 context，那部分逻辑就会脱离追踪链。写工具函数封装 span 创建和 context 传递，比每次手写更可靠。
