Golang微服务链路追踪核心是用OpenTelemetry通过context透传traceparent等W3C标准Header，在HTTP/gRPC入口解析、中间件自动埋点、下游调用Inject/Extract，统一初始化TracerProvider并配置Exporter。
在Golang微服务中实现链路追踪，核心是统一传递和延续请求的唯一标识（TraceID），并在各服务间透传上下文（Context），配合OpenTracing或OpenTelemetry标准埋点。不依赖复杂中间件，Gin、gRPC、HTTP客户端等均可轻量集成。
用context传递TraceID和Span信息
Go的context.Context是天然的跨层传递载体。每次收到请求时生成或提取TraceID，并注入到Context中，后续调用（如HTTP请求、数据库操作、下游gRPC）都基于该Context构建子Span。
- HTTP入口：从请求Header（如
trace-id、span-id、parent-span-id）解析并构建初始Span - gRPC服务：通过
grpc.UnaryInterceptor自动注入/提取metadata.MD中的追踪字段 - 下游调用：用
ctx = otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header))透传
选择OpenTelemetry替代已归档的OpenTracing
OpenTracing已于2023年正式归档，OpenTelemetry（OTel）成为CNCF推荐的标准。Golang生态已全面转向go.opentelemetry.io/otel。
- 初始化全局TracerProvider，配置Exporter（如Jaeger、Zipkin、OTLP）
- 使用
tracer.Start(ctx, "service-name.method")创建Span，显式结束span.End() - 为Span添加属性：
span.SetAttributes(attribute.String("http.method", r.Method)) - 错误自动标记：
span.RecordError(err)+span.SetStatus(codes.Error, err.Error())
HTTP与gRPC中间件自动埋点
避免每个Handler手动Start/End Span，封装通用中间件：
立即学习“go语言免费学习笔记（深入）”；
- Gin中间件：解析
X-Trace-ID，创建Span，注入Context到c.Set("ctx", ctx)，并在c.Next()后结束Span - gRPC UnaryServerInterceptor：从
metadata.FromIncomingContext(ctx)提取trace信息，新建Span并重写Context - HTTP Client中间件：用
http.RoundTripper包装，在Do前Inject，在响应后可选记录延迟
跨服务透传需保持Header一致性
链路断裂常因Header未透传或命名不一致。统一约定关键Header名（推荐W3C标准）：
-
traceparent：W3C格式（如00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01），必须透传 -
tracestate：可选，用于多厂商兼容 - 避免自定义
X-Trace-ID混用——若用OTel，优先走traceparent，否则需在Propagator中注册自定义TextMapPropagator
基本上就这些。链路追踪不是加一堆SDK，而是理清Context生命周期、规范透传方式、选对标准（OTel）、用好中间件。初期跑通一条HTTP→gRPC→DB链路，后面扩展就顺了。
