根本原因是HTTP请求头未透传X-B3-TraceId等字段且服务端未用zipkinhttp.NewServerMiddleware解析，导致上下文无法注入；客户端须每次Do前调tracer.Inject，服务端入口须用Extract恢复context，否则span变为孤立root。
为什么 Go 微服务里 Zipkin 的 traceID 不跨服务传递？
根本原因是 HTTP 请求头没透传 trace-id、span-id 和 parent-span-id，或者中间件没把它们注入到 OpenTracing 上下文。Go 默认的 http.Client 不自动携带 header，下游服务也默认不解析这些字段。
实操建议：
- 用
opentracing-go+zipkin-go组合，避免混用jaeger-client-go等其他 tracer 实现 - 所有 HTTP 客户端请求前，必须调用
tracer.Inject将当前 span 注入到http.Header中，常见错误是只 inject 了 traceID 而漏掉parent-span-id - HTTP 服务端入口处，用
tracer.Extract从req.Header恢复上下文，否则新 span 会变成 root span - 别依赖
context.Background()创建 span；必须用opentracing.ContextWithSpan(ctx, span)把 span 塞进 context 传递
如何让 Gin / Echo / net/http 中间件自动完成 Zipkin 上下文传播？
手动 Inject/Extract 极易遗漏，尤其在多层中间件或异步 goroutine 场景下。必须封装成统一中间件，且注意 goroutine 启动前要显式拷贝含 span 的 context。
关键点：
立即学习“go语言免费学习笔记（深入）”；
- Gin 中间件示例：在
c.Request.Header中调用tracer.Extract，失败时新建 root span；响应前用tracer.Inject写回c.Writer.Header() - Echo 同理，但需注意
echo.Context.Request().Header是只读副本，Inject 必须作用于原始http.Request - 遇到 goroutine（比如发 MQ、调第三方 API），不能直接用
go func(){}()，得写成go func(ctx context.Context) { ... }(c.Request.Context()) - 别在中间件里调
span.Finish()—— 应该在 handler 执行完后由 defer 触发，否则可能提前结束 span
Zipkin 采样率设成 1.0 还是 0.001？什么时候该调？
全量上报在高 QPS 下会压垮 Zipkin Server 和网络带宽，但采样率太低又查不到关键链路。这不是“越准越好”，而是权衡可观测性与资源消耗。
推荐做法：
- 线上默认用
0.01（1%）采样，通过zipkin-go.NewSampler设置；对 error 状态的请求强制采样：检查span.Tag("error", true)后调用sampler.AlwaysSample() - 测试环境可设为
1.0，但务必关掉日志级 span（比如 DB 查询参数、HTTP body），否则 zipkin-server 日志爆炸 - 不要在每次请求都 new 一个 sampler —— 复用全局 singleton，否则 GC 压力大且采样逻辑不一致
- 注意：
zipkin-go的采样器只影响本进程 span 创建，不控制下游服务是否采样；跨服务链路完整性依赖每跳都开启采样
为什么 Zipkin UI 显示 span 时间不准，或父子关系错乱？
最常见原因是时间戳没对齐或 span 生命周期管理错误，不是 Zipkin 本身问题，而是 Go client 使用方式不对。
排查重点：
- 确保所有 span 都调用了
span.Finish()—— 尤其在 panic recover 或 early return 分支里漏掉，会导致 span 悬挂、时间截断 - 避免用
time.Now().UnixNano()手动设startTime；应统一用tracer.StartSpan自动打点，它内部已做 monotonic clock 校准 - 父子 span 关系靠
childOf或followsFrom引用决定，不是靠命名或嵌套顺序；如果用了tracer.StartSpan("db", opentracing.ChildOf(parentCtx))却传了 nil parentCtx，就会变成孤立 span - Zipkin 的 timestamp 是微秒级，而 Go
time.UnixNano()是纳秒；zipkin-go内部做了除 1000 转换，但若你手动 set timestamp，必须自己除 1000，否则时间快 1000 倍
跨服务链路能连上，不代表每个 span 都准；真正难的是让时间轴对齐、父子关系可推导。这要求每一跳的 Go 服务都严格遵循 OpenTracing 语义，而不是只求 UI 上看起来连通。
