线程池异步任务中MDC日志变量丢失的根本原因是上下文未随线程切换传递，需在任务提交前捕获MDC副本、执行前还原，并在Web拦截器中统一注入与清理。
线程池执行异步任务时，MDC 中的 traceId、requestId 等日志变量丢失，本质是上下文未随线程切换而传递。解决的关键不在于“换线程池”，而在于在任务提交与执行两个环节主动捕获和还原 MDC 内容。下面从拦截器配合角度给出可直接落地的实战方案。
Web 层拦截器：统一注入并清理 MDC
这是整个链路的起点，必须确保每次请求进来就绑定唯一标识，并在退出时及时清理，避免线程复用污染：
- 使用 HandlerInterceptor 的
preHandle方法生成或提取 traceId（如从 Header 获取或自动生成），调用MDC.put("traceId", id) - 在
afterCompletion中必须执行MDC.clear()，不能只 remove 单个 key，否则残留其他字段（如 userId）会跨请求污染 - 若使用 Spring WebFlux 或 Filter，对应改用 WebFilter 或 OncePerRequestFilter，逻辑一致
线程池任务包装：让 Runnable/Callable 携带上文
原生线程池不感知 MDC，需在提交任务前“快照”当前 MDC，并在子线程执行前恢复：
- 手动包装最简单可靠：
executor.submit(MdcRunnable.wrap(() -> doAsyncWork())) -
MdcRunnable 构造时调用
MDC.getCopyOfContextMap()保存副本，run()中先MDC.setContextMap(...)再执行业务逻辑，结束后MDC.clear() - 对
Callable同理，封装为 MdcCallable，适用于需要返回值的场景
Spring 场景推荐：继承 ThreadPoolTaskExecutor 并重写 execute/submit
若项目已用 @EnableAsync 或 ThreadPoolTaskExecutor，建议扩展其行为，避免散落各处的手动包装：
- 自定义类继承
ThreadPoolTaskExecutor，重写execute(Runnable)和submit(Callable) - 在重写方法中，自动将入参包装为
MdcRunnable或MdcCallable，再调用父类方法 - 配置类中注入该定制线程池，Spring 的
@Async将自动走增强逻辑，零侵入适配现有异步方法
生产环境必须注意的细节
很多问题不是方案不行，而是细节遗漏导致失效：
- 禁止在子线程里调用 MDC.clear() 后再 log——clear 后后续日志无法输出 traceId，应放在 finally 块末尾
- 若用 CompletableFuture，不能只对
supplyAsync包装，thenApply、thenAccept等回调线程也需透传，建议统一用defaultExecutor替换为带 MDC 支持的线程池 - 日志框架需启用 %X{traceId} 格式，logback.xml 中 pattern 示例：
[traceId:%X{traceId}] %d %-5level %c{36} - %m%n
