应采用OpenTelemetry Go SDK + Jaeger导出器替代已归档的jaeger-client-go，通过标准化中间件自动埋点、正确透传context、适配数据库与HTTP/gRPC客户端，并用stdoutexporter和traceparent头快速验证链路完整性。
Go语言集成Jaeger实现微服务全链路监控，核心在于正确初始化追踪器、确保Span上下文全程透传、并选用适配当前生态的组件。需特别注意：jaeger-client-go 已归档，新项目应优先采用 OpenTelemetry Go SDK + Jaeger 导出器组合，这是2026年生产环境的事实标准。
选对SDK：用OpenTelemetry替代jaeger-client-go
官方已停止维护 jaeger-client-go（归档状态），它不支持现代 Go 的 context 透传模型，易导致 goroutine 中 span 断裂或丢失。OpenTelemetry Go SDK 是当前统一标准，兼容 Jaeger 后端，导出配置灵活：
- 使用 go.opentelemetry.io/otel/exporters/jaeger 或更推荐的 OTLP over HTTP（通过
otlphttp.NewClient()）对接 Jaeger Collector - 避免硬依赖 UDP 端口（如 6831），改用 HTTP 接口（默认 14268）提升稳定性与可观测性
- 初始化 tracer provider 必须在
main()开头完成：otel.SetTracerProvider(tp)，否则所有Tracer().Start()都退化为 noop
入口埋点：HTTP/gRPC服务自动注入Span
手动逐个 StartSpan 容易遗漏且难以对齐请求生命周期。应借助标准化中间件实现自动化：
- Gin 服务：使用
go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin中间件，自动提取traceparent并创建入口 span - gRPC 服务：必须启用
otelgrpc.UnaryServerInterceptor和otelgrpc.UnaryClientInterceptor，否则 unary 调用不会生成子 span - HTTP 客户端调用下游：禁用
http.DefaultClient，改用otelhttp.NewClient()实例，自动 inject trace headers
上下文透传：防止链路断裂的关键细节
90% 的“链路只显示单个服务”问题源于 context 未正确传递或 span 提前结束：
立即学习“go语言免费学习笔记（深入）”；
- 跨 goroutine 必须显式传入
req.Context()，写成go doWork(ctx)而非go doWork() - 异步定时任务（如
time.AfterFunc）中，原 context 可能已被 cancel，应在回调内重新获取 span 或使用otel.WithSpanFromContext - DB 调用需 wrap：MySQL 用
otelmysql.Wrap，PostgreSQL 用otelpostgresql.Wrap，否则 SQL 执行不计入 span - 手动创建子 span 时，始终从
req.Context()获取 parent，禁止使用context.Background()
调试与验证：快速确认是否生效
上线前建议本地验证链路完整性，避免部署后才发现数据缺失：
- 开发阶段启用
stdoutexporter：终端直接输出 JSON 格式 span，比查日志快得多 - 检查 HTTP 响应头是否含
traceparent字段，确认出口透传正常 - Jaeger UI 中观察 trace 是否包含多个 service name，且父子 span 有明确
child_of关系 - 若链路断裂，优先检查 propagator 是否支持多格式——旧系统常用 B3 头，需注册复合 propagator：
propagation.NewCompositeTextMapPropagator(propagation.TraceContext{}, propagation.B3{})
