排查trace_id断层需检查mdc是否被意外清空、覆盖或未传递：1.拦截器/过滤器中提前clear()；2.@around切面未调用proceed()或吞异常；3.跨线程场景未透传mdc；4.通过日志+断点定位断点。

排查多层切面或拦截器嵌套中因错误捕获导致 trace_id 断层，核心在于确认 MDC 上下文是否在任意一层被意外清空、覆盖或未传递。这类问题不表现为编译报错，而是在日志中突然出现 %X{TRACE_ID} 为空，或同一请求前后日志出现两个不同 trace_id。

检查拦截器/过滤器是否提前清除 MDC

很多老项目会在权限校验、日志记录等拦截器末尾调用 MDC.clear()，意图“释放资源”。但若该拦截器位于链路中间（非最外层），就会切断后续逻辑的上下文。尤其注意以下场景：

• 自定义 OncePerRequestFilter 中，在 doFilter 结束前执行了 MDC.clear()
• Spring Interceptor 的 afterCompletion 方法里无条件清空 MDC
• 全局异常处理器（@ControllerAdvice）在处理异常后主动清空 MDC，却未考虑当前请求尚未结束

验证切面中是否遗漏 proceed() 或吞掉异常

使用 @Around 切面时，若逻辑分支中未调用 pjp.proceed()，或在 catch 块中静默处理异常而不重新抛出，会导致后续拦截器、控制器方法完全不执行，MDC 自然无法延续。

• 检查所有 @Around 方法，确保每个执行路径都包含且仅包含一次 pjp.proceed()
• 避免在 try-catch 中捕获异常后仅打日志却不 throw e 或 rethrow
• 特别留意带重试、熔断、降级逻辑的切面，它们最容易引入“短路”行为

确认跨线程场景下 MDC 未丢失

即使单线程流程正常，一旦涉及异步（@Async、线程池、CompletableFuture）、消息监听（Kafka Listener）、定时任务（@Scheduled），MDC 默认不会自动传递。

• 查看是否有 ThreadPoolTaskExecutor 自定义，但未包装为支持 MDC 透传的装饰器
• Kafka 消费者中是否在 @KafkaListener 方法开头手动从 header 提取 trace_id 并塞入 MDC
• 定时任务是否每次执行都新建 trace_id，而非继承触发源头的上下文（如 Quartz Job 中需显式传递）

定位具体断点：用日志+断点双验证

不要只依赖最终日志输出。在关键节点插入调试日志，打印 MDC.get("TRACE_ID") 和当前线程名：

• 网关入口过滤器首行
• 各拦截器 preHandle / doFilter 开始与结束处
• 切面 @Around 的前置、proceed() 前后、后置逻辑中
• Controller 方法第一行

对比同一请求 ID（如 Nginx 日志中的 $request_id）对应的所有日志行，观察 trace_id 从哪一环开始变空或突变，即可快速锁死问题组件。