opentracing go通过标准tracer接口实现厂商无关的追踪切换：业务代码仅依赖opentracing-go，调用startspan等方法，初始化时传入jaeger/zipkin/datadog等具体实现，替换tracer实例即可无缝切换后端，无需修改业务逻辑。
直接对接 Jaeger、Zipkin 或 Datadog，不需要改业务代码——只要替换 Tracer 实现，就能切换后端。核心在于用标准接口隔离厂商细节，而不是硬编码某家 SDK。
opentracing-go 的 Tracer 接口怎么换不破业务逻辑
OpenTracing 的价值就在这里：opentracing-go 只定义接口，不实现采集和上报。你调用的 opentracing.StartSpanFromContext、span.SetTag 等函数，背后实际执行的是你传进去的 Tracer 实例。
- 初始化时调用
opentracing.SetGlobalTracer(your_impl.New())，后续所有opentracing.GlobalTracer()都返回这个实例 - Jaeger 用
jaeger.NewTracer，Zipkin 用zipkinhttp.NewReporter+zipkin.NewTracer，Datadog 用ddtrace.New——它们都实现了opentracing.Tracer接口 - 业务代码里完全不 import 厂商包，只依赖
github.com/opentracing/opentracing-go - 如果某天要从 Jaeger 切到 OTLP，只需改一行 new tracer 的代码，其余零改动
HTTP 跨服务传播必须配对 Inject/Extract
链路断开最常见原因不是 tracer 没初始化，而是 header 传递没对齐。发送方用了 HTTPHeaders 注入，接收方却用 text_map 提取，或者压根没调用 Extract。
- 发送端务必用：
tracer.Inject(span.Context(), opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(req.Header)) - 接收端必须先提取：
wireCtx, err := tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header))，再用它创建 root span 或继续 child span - 注意：Go 的
net/http不自动处理这些 header，必须显式写在中间件里，不能只靠框架默认行为 - 验证是否生效：curl -H 'traceparent: 00-12345678901234567890123456789012-1234567890123456-01' http://your-service/health，看下游日志里
span.Context().TraceID()是否匹配
go-zero 等框架里 tracer 初始化时机很关键
在 go-zero 中，如果把 opentracing.SetGlobalTracer 放在配置加载之后、RPC server 启动之前，但又晚于拦截器注册，就会导致部分请求走 noop tracer —— 因为拦截器已经拿着旧的（nil）tracer 开始工作了。
- 必须在
main()最开头就设置全局 tracer，早于任何服务注册、路由初始化、zrpc client 创建 - 不要放在
init()函数里：Go 的init执行顺序不确定，尤其涉及多个包时，可能 tracer 还没 ready，HTTP handler 就已启动 - 检查是否生效：打印
opentracing.GlobalTracer() != nil和opentracing.GlobalTracer().(fmt.Stringer).String()（部分实现支持），避免静默失败 - 如果用的是 OpenTelemetry 兼容层（如
opentracing.Wrap），确认 wrap 后的 tracer 仍满足 goroutine-safe，否则并发下 span 可能错乱
真正容易被忽略的不是怎么写 span，而是 tracer 生命周期和上下文传播的边界——比如异步 goroutine 里忘了用 context.WithValue 传递 span context，或者 HTTP 中间件里 extract 失败却没 fallback 到新建 root span，结果整条链路只剩孤岛 span。
