go服务接入jaeger的核心是确保span正确串联：必须显式初始化tracer并传入非空service-name，http/grpc需配对拦截器透传context，避免全局tracer复用或跨goroutine误调finish。
Go 服务接入 Jaeger 追踪，核心不是“能不能”，而是“怎么让 span 正确串联且不漏传”——关键在 context 传递、tracer 初始化时机和 HTTP/gRPC 拦截器的配置一致性。
初始化 tracer 时必须指定 service-name 且避免复用全局变量
Jaeger 的 tracer 不是线程安全的单例，但 Go 中常误用 opentracing.GlobalTracer() 导致跨 goroutine 覆盖或 nil panic。正确做法是显式创建并注入到依赖中（如 HTTP handler 或 gRPC server）。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference（调用 StartSpan 时 tracer 为 nil）；或多个 service 共享同一 tracer 导致 tag 混淆。
- 用
jaeger.New(...)创建 tracer，并传入service-name（必须与 Jaeger UI 中的服务名一致，区分大小写） - 不要调用
opentracing.SetGlobalTracer()，除非你明确控制所有 span 创建路径 - 若用 Gin/Echo，把 tracer 作为中间件参数传入，而非从全局取
- 注意
reporter.localAgentHostPort默认是localhost:6831，K8s 环境需改为 Jaeger Agent 的 Service 名（如jaeger-agent.default.svc.cluster.local:6831）
HTTP 请求中手动注入/提取 trace context 的位置很关键
Go 标准库 http.ServeMux 不自动处理 traceparent 或 Jaeger 的 uber-trace-id header，必须在 handler 开头显式提取，在下游调用前注入。
使用场景：服务 A → HTTP 调用 → 服务 B，若 A 不把当前 span context 注入 request.Header，则 B 收不到 parent span，链路断裂。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header))从入参*http.Request提取 - 创建子 span 时传入
opentracing.ChildOf(spanCtx)，而非opentracing.StartSpan空参数 - 下游请求前，用
tracer.Inject(span.Context(), opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(req.Header))注入 - 别忽略
err != nil分支：提取失败时应 fallback 到opentracing.StartSpan()新建 root span，否则整条链断成多段
gRPC 客户端和服务端必须配对启用拦截器
gRPC 的 metadata 是 context 传播载体，但默认不透传 tracing header。只配客户端拦截器而没配服务端，或反之，都会导致 span 断裂。
性能影响：每个 RPC 调用增加约 2–5μs 开销（实测于 Jaeger v1.32 + grpc-go v1.58），可接受；但若未关闭 debug 日志（jaeger.ReporterOptions.Logger），日志刷屏会显著拖慢吞吐。
- 客户端拦截器：用
grpc.WithUnaryInterceptor(otgrpc.OpenTracingClientInterceptor(tracer)) - 服务端拦截器：用
grpc.UnaryInterceptor(otgrpc.OpenTracingServerInterceptor(tracer)) - 确保
otgrpc版本与opentracing和jaeger-client-go兼容（v1.4.x 对应 Jaeger v1.29+） - 若用 streaming，还需额外配置
Stream*Interceptor，否则 stream 消息不带 trace
Span 生命周期管理最容易被忽略的三个点
Go 的 defer 常被误用于 span.Finish()，但若 handler panic 或提前 return，span 可能未结束，或结束两次（Finish() 非幂等但多次调用会 log warn 并丢弃后续事件）。
- span 必须在对应 goroutine 内 Finish()，跨 goroutine 调用
span.Finish()会导致 context 错乱 - 数据库查询、Redis 调用等异步操作，应在 callback 或 goroutine 内新建 child span，而不是复用 handler 的 span
- HTTP handler 中，span 应在 writeHeader 后 Finish()，否则 5xx 错误可能无法打上 error tag；可用
defer func() { if r := recover(); r != nil { span.SetTag("error", true) } span.Finish() }()容错
最复杂的不是代码量，是跨协议（HTTP/gRPC）、跨进程（本地 goroutine vs 远程调用）、跨错误路径（panic / timeout / network fail）时 context 的保真度——哪怕一个 header 没传、一个 defer 写错位置，整条 trace 就碎成几截。
