因为ThreadLocal线程绑定，RabbitMQ消费线程池复用导致父线程traceId无法自动传递，需通过消息header手动透传并在onMessage中注入MDC，且必须try-finally清理避免污染。
为什么 @RabbitListener 的 ThreadLocal 会丢失链路 ID
spring amqp 默认用 simplemessagelistenercontainer 启动多个消费者线程，每个消息由独立线程处理。而 threadlocal 是线程绑定的——旧线程里存的 trace id（比如 mdc 中的 traceid）不会自动传递到新线程，导致日志中链路断裂。
用 MessagePostProcessor + 自定义 ChannelAwareMessageListener 注入上下文
不能只靠拦截器或 AOP，因为 RabbitMQ 消费入口在容器线程池里，必须在消息真正被消费前把父上下文（如 HTTP 请求中的 trace ID）注入新线程。关键点是：在发送端塞入 header，在消费端从 header 提取并初始化 ThreadLocal。
- 发送方需手动把当前 trace ID 写进消息 header：
message.getMessageProperties().setHeader("X-B3-TraceId", MDC.get("traceId")) - 消费端需自定义
ChannelAwareMessageListener包装原 listener，重写onMessage：先从message.getMessageProperties().getHeaders()取出 trace ID，再用MDC.put("traceId", ...)初始化当前线程的 MDC - 务必在
try-finally块中清理：MDC.clear()，否则线程复用时会污染后续消息
@RabbitListener 配合 ThreadPoolTaskExecutor 时的线程池陷阱
如果用 ConcurrentMessageListenerContainer 或自定义线程池，容易忽略线程池的 ThreadFactory 配置。默认线程工厂创建的线程不继承任何上下文，且无法通过 InheritableThreadLocal 自动传递（因为 Spring AMQP 不走 new Thread() 而是复用线程）。
- 不要依赖
InheritableThreadLocal—— 它只对new Thread(runnable)有效，对线程池无效 - 避免在
afterPropertiesSet()或@PostConstruct中初始化 MDC —— 这些方法运行在主线程，和消费线程无关 - 若使用
ThreadPoolTaskExecutor，建议显式设置setThreadFactory，但仅用于命名线程，上下文仍需靠消息 header +onMessage注入
SLF4J MDC 和 OpenTracing/Spring Cloud Sleuth 的兼容性注意点
如果项目已集成 Sleuth，它默认会自动透传 traceId 和 spanId 到 RabbitMQ 的 header，并在消费端还原 MDC。但前提是：你没覆盖默认的 TracingChannelInterceptor，且未禁用 spring.sleuth.messaging.enabled=true（Spring Boot 2.6+ 默认开启）。
- 检查是否误删了
@EnableAsync或@EnableScheduling相关配置 —— Sleuth 的 RabbitMQ 支持依赖spring-cloud-starter-sleuth和spring-cloud-starter-bus-amqp（旧版）或spring-cloud-starter-loadbalancer（新版）的间接传递 - 若手动管理 MDC，确保 trace ID 格式与 Sleuth 一致（如 16 或 32 位 hex），否则
TraceContext解析失败，Span会新建而非续接 - 日志框架必须是 SLF4J + Logback（或 Log4j2 的
ThreadContext），且 pattern 中包含%X{traceId}才能输出
