必须从Delivery.Headers显式提取traceparent并用OTel传播器解析，否则链路断裂；提取失败时应创建新root span而非fallback到Background()，且goroutine需传入派生context而非捕获外部ctx。
必须从消息 headers 中显式提取 traceparent，再注入新 context；否则链路在消费端直接断裂，Jaeger 里只看到孤立的 kafka-consume 或 rabbitmq-consume span。
如何从 RabbitMQ Delivery.Headers 提取并还原 SpanContext
RabbitMQ 的 Delivery 对象不自动携带 OpenTelemetry 上下文，traceparent 必须存在 Delivery.Headers 中，且需用标准传播器解析，不能手动字符串拆解。
- 使用
otel.GetTextMapPropagator().Extract()，传入propagation.MapCarrier(delivery.Headers)，不是delivery.Header.Get("traceparent") - 若提取失败（比如上游没发、header 被丢弃、key 名写错），不要 fallback 到
context.Background()，而应调用tracer.Start(ctx, "rabbitmq-consume", trace.WithNewRoot())创建新 trace - 确保上游生产端已用
otel.GetTextMapPropagator().Inject(ctx, propagation.MapCarrier(msg.Headers))注入，否则这里永远拿不到
goroutine 启动时 traceID 丢失的典型写法与修正
消费回调里常启 goroutine 处理耗时逻辑，但闭包捕获外部 ctx 是最大陷阱——新 goroutine 实际运行在 context.Background() 上，span 父子关系彻底断裂。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 错误写法：
go func() { db.QueryRow(ctx, ...) }—— 这里的ctx是外层变量，但未被传入函数签名 - 正确写法：
go func(ctx context.Context) { db.QueryRow(ctx, ...) }(childCtx)，其中childCtx是从tracer.Start(extractedCtx, ...)返回的新 context - 若带超时，用
context.WithTimeout(childCtx, 5*time.Second)派生，别用context.Background()包一层再传
HTTP 入口 + RabbitMQ 发送混合链路中 traceID 不一致怎么办
一个 HTTP 请求触发业务逻辑后异步发 RabbitMQ 消息，结果 Jaeger 显示两个独立 trace，说明发送端没复用 handler 的 context，而是新建了 root span。
- HTTP handler 中：先
ctx, span := tracer.Start(r.Context(), "http-handler")，然后所有后续操作（包括发消息）都基于这个ctx - 发消息前：用
otel.GetTextMapPropagator().Inject(ctx, propagation.MapCarrier(msg.Headers))把当前 span context 写进 headers - 别在
tx.Commit()后才启动 goroutine 发消息——commit 会 cancel 关联 ctx，导致 span.End() 失败或 status 错误
最容易被忽略的是：RabbitMQ 消费端拿到的 Delivery 是原始字节载体，headers 是否被中间件/代理/客户端自动 strip，取决于 AMQP 协议版本和 broker 配置；上线前务必用 fmt.Printf("%v", delivery.Headers) 实锤验证 traceparent 是否真实抵达。
