Go HTTP客户端需手动透传W3C标准traceparent（00-{32位traceID}-{32位spanID}-01）及tracestate，服务端须用propagator.Extract并注入context，goroutine中应传span而非ctx，日志需显式集成traceID。
Go HTTP 客户端怎么透传 traceID 和 spanID
靠手动塞 header，别信中间件自动帮你做——标准 http.Client 不会读取或传播 context 中的 tracing 信息。你得在每次发起请求前，显式从当前 context.Context 提取 span，并把 traceID、spanID、traceflags 写进 traceparent header。
常见错误是只传 X-Trace-ID 这种自定义字段，结果下游用 OpenTelemetry 或 Jaeger SDK 时压根不识别，链路直接断掉。
- 必须用 W3C 标准格式：
traceparent: 00-{traceID}-{spanID}-01（注意 traceID/spanID 都是 32 位小写十六进制，不足补 0） - 如果下游是 OTel，还要加
tracestateheader 传递 vendor-specific 状态（比如tracestate: otel=00000000000000000000000000000001） - 别用
req.Header.Set()直接覆盖，要用req.Header.Add()避免被其他中间件清空（某些代理或 SDK 会重写 header）
Go HTTP 服务端如何从 request 提取并延续 span
关键不是“收到 header 就解析”，而是要确保提取后创建的新 span 真正继承了 parent 的 traceID 和采样决策。OpenTelemetry Go SDK 的 otelhttp.NewHandler 默认支持 traceparent，但前提是你的 handler 是它包装过的。
容易踩的坑：自己手写 middleware 解析 traceparent 后，用 trace.SpanFromContext(r.Context()) 拿到的还是空 span —— 因为没把解析出的 span context 注入到 request context 里。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：用
propagators.TraceContext{} .Extract(r.Context(), r.Header)得到propagation.MapCarrier，再用tracer.Start(r.Context(), "handler", trace.WithSpanKind(trace.SpanKindServer)) - 如果用了 Gin/Echo，别在中间件里用
c.Request = c.Request.WithContext(...)，Gin v1.9+ 要求用c.Set("span", span)+ 显式传参，否则 context 注入失效 - 注意
traceparent中的 traceflags（第3段）决定是否采样：01表示 sampled，00表示 not sampled；别硬编码采样逻辑覆盖它
goroutine 里怎么保持 trace 上下文不丢失
Go 的 goroutine 不自动继承父 goroutine 的 context，所以 go func() { ... }() 里调用 DB 或 RPC 时，span 会变成独立 root，链路断裂。
最直接的办法不是“传 context”，而是把 span 本身作为参数传进去——因为 span 是 thread-safe 的，且自带 context。
- 错误写法：
go doWork()→doWork()里用trace.SpanFromContext(context.Background())，得到 nil - 正确写法：
span := trace.SpanFromContext(ctx); go doWork(span)，然后在doWork里用span.Tracer().Start(span.Context(), "subtask") - 如果用
errgroup.Group，记得用eg.Go(func() error { return doWork(span) })，别让 eg 自己 new context - 切忌在 goroutine 里调
context.WithValue塞 span，OTel 的 propagator 不认这种 fake context
为什么本地日志没打上 traceID —— context.Value vs. logrus/zerolog 集成
日志库不会自动读 context 里的 traceID，哪怕你用 ctx = trace.ContextWithSpan(ctx, span)，logrus 也看不到。必须显式把 traceID 注入 logger 实例或字段。
zerolog 更麻烦：它的 ctx.Log() 方法看似能读 context，但默认不启用 traceID 提取，需要配 zerolog.CtxHook。
- logrus 方案：注册
logrus.Entry.WithContext(ctx).WithField("trace_id", traceID)，其中traceID从trace.SpanFromContext(ctx).SpanContext().TraceID().String()拿 - zerolog 推荐：用
zerolog.Ctx(ctx).Info().Msg("xxx")，但前提是初始化 logger 时加了zerolog.NewConsoleWriter()+zerolog.CtxHook(true)（v1.30+） - 别在每条日志前手动拼
fmt.Sprintf("[trace:%s] %s", traceID, msg)，破坏结构化日志，也容易漏
traceID 格式不统一是最隐蔽的问题：HTTP header 里是 32 位 hex，但有些 SDK 输出日志时默认转成 16 字节 []byte，看着像乱码。检查日志字段值是不是以 0000000000000000 开头，就知道有没有被截断或误转。
