消息追踪需统一context传递、处理消息头透传、继承异步goroutine的context；Kafka/RabbitMQ消费时须从headers提取traceID并注入新context，goroutine必须显式传入ctx，HTTP与消息链路需复用同一traceID，span.End()和exporter flush不可遗漏。
Go 里做消息追踪（比如 Kafka、RabbitMQ 消费）和 HTTP 链路跟踪，本质都是把 traceID 贯穿到异步或跨服务调用中。不统一 context 传递、不处理消息头透传、忽略异步 goroutine 的 context 继承，这三件事做错一个，链路就断了。
消息消费时怎么延续上游 traceID
消息中间件本身不带 context，traceID 必须从消息 payload 或 headers 显式提取，再注入新 context。Kafka 支持 Headers（v0.11+），RabbitMQ 可用 Delivery.Headers，但别直接塞进业务 struct——下游没法自动感知。
- 消费端收到消息后，先调用
otel.GetTextMapPropagator().Extract()从消息 headers 中还原 span context，而不是手动解析"traceparent"字段 - 提取失败时，不要 fallback 到
context.Background()，而应创建 new root span：tracer.Start(ctx, "kafka-consume", trace.WithNewRoot()) - 若消息来自 HTTP 入口（如 webhook 推送到 Kafka），确保生产端已用
otelhttp.NewHandler自动注入 headers；否则需在发消息前手动 inject：otel.GetTextMapPropagator().Inject(ctx, propagation.MapCarrier(msg.Headers))
goroutine 启动时 traceID 丢失的典型场景
常见错误是写 go func() { /* 处理逻辑 */ }() 却没把 ctx 传进去，导致新 goroutine 用的是 context.Background()，span 父子关系断裂，traceID 变成新生成的。
- 必须显式传参：
go func(ctx context.Context) { ... }(r.Context())，不能闭包捕获外部ctx变量（可能已被 cancel 或覆盖） - 涉及定时任务、延迟重试、批量处理时，用
context.WithTimeout()或context.WithDeadline()包一层再传，避免长任务拖垮整个 trace 生命周期 - 数据库事务内启 goroutine？别在
tx.Commit()后才启动——commit 会 cancel 关联 ctx，导致 span 提交失败或 status 错误
HTTP + 消息混合链路中 traceID 不一致
同一个请求触发 HTTP 响应 + 异步发 Kafka 消息，结果 Jaeger 里看到两个独立 trace，说明 traceID 没复用，而是各自 new 了。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 根本原因是：HTTP handler 里用
tracer.Start(r.Context(), "http-handler")创建 span 后，没把返回的ctx（含 span）往下传，后续发消息时又调了tracer.Start(context.Background(), "kafka-produce") - 正确做法：所有后续操作都基于 handler 返回的新 ctx：
ctx, span := tracer.Start(r.Context(), "http-handler"); defer span.End(); ... sendToKafka(ctx) - 如果用的是封装好的 client（如
sarama.AsyncProducer），它不接受 ctx，就得提前把traceID和spanID提取出来，塞进消息 headers，再在消费端重建 span —— 但这样会丢失父子 span 关系，仅保留 traceID，慎用
日志与 traceID 对不上号的隐蔽原因
看着日志里打了 [trace_id:xxx]，但在 Jaeger 找不到对应 trace，大概率是 span 没结束或 exporter 没 flush。
-
span.End()必须执行，且不能被 defer 在 panic recover 外层吞掉；尤其注意 defer 写在 if err != nil 分支里，会导致成功路径漏掉 End - 应用退出前（如
os.Interrupt信号）要显式调tp.Shutdown(context.Background())，否则最后一批 span 丢在内存里 - 本地开发用
stdoutexporter 测试时，别开WithSyncer(os.Stderr)却往log.Printf写，日志和 trace 输出不同步，容易误判
最易被忽略的一点：消息体序列化时如果用了 JSON，而 headers 是 map[string]interface{}，某些 SDK（如早期 sarama）会把 traceparent 这种带连字符的 key 自动转成驼峰，导致 extract 失败。检查实际发送的 headers key 名是否原样保留，比调通逻辑更优先。
