mdc是java日志中实现traceid的核心机制，通过threadlocal在请求入口注入、出口清理，并配合日志配置%x{traceid}自动输出，无需修改原有日志语句；异步场景需手动传递mdc上下文。
闭包本身不是 Java 或主流日志框架中实现 TraceID 的核心机制——真正起作用的是 MDC（Mapped Diagnostic Context） 这种线程绑定的上下文容器，配合过滤器/拦截器在请求生命周期内“自动注入 + 自动清理”。所谓“用闭包实现”，实际是误传或概念混淆：Java 没有原生闭包语法，而 JavaScript/Go 等语言虽支持闭包，但在服务端日志追踪中，TraceID 的传递依赖的是显式上下文透传（如 OpenTelemetry 的 Context API），而非闭包捕获变量。
关键点：MDC 才是日志中自动带 TraceID 的基础
SLF4J 的 MDC 是一个 ThreadLocal 映射表，它让当前线程的日志输出能自动携带键值对（如 "TID"）。只要你在请求开始时 MDC.put("TID", traceId)，并在结束时 MDC.remove("TID")，后续所有 log.info() 就会自动带上该 ID——无需修改每行日志语句。这本质上是“上下文自动注入”，不是闭包行为。
- 日志框架（Logback / Log4j2）通过
%X{TID}在 pattern 中读取 MDC 值，实现零侵入输出 - Filter 或 Interceptor 是最常用、最稳妥的注入入口，覆盖所有 HTTP 请求
- 必须 确保 finally 块中 remove，否则线程复用会导致 TraceID 泄漏污染
异步场景下需手动“传递上下文”，不是靠闭包
当业务中使用线程池、CompletableFuture、@Async 等，新线程无法继承父线程的 MDC。此时需显式复制上下文：
- 使用
MDC.getCopyOfContextMap()获取当前 MDC 快照 - 在线程启动前调用
MDC.setContextMap(...)注入 - 执行完后调用
MDC.clear()清理（尤其在线程池复用场景） - Spring Boot 可结合
ThreadPoolTaskExecutor的setThreadFactory或自定义AsyncConfigurer统一处理
定时任务与 XXL-Job 中补全 TraceID
定时任务不走 Web 请求链路，没有天然入口注入 TraceID。需主动补全：
- 在 @Scheduled 方法开头调用
MDCTraceUtils.addTraceId()（见知识库工具类） - XXL-Job 任务处理器中同样手动
addTraceId()，并在finally中removeTraceId() - 若任务触发上游有 TraceID（如由 API 调用触发），可通过参数或上下文透传，再用
MDCTraceUtils.putTraceId(...)注入
日志格式与输出配置要匹配 key 名
无论你用 "TID"、"traceId" 还是 "EagleEye-TraceID"，必须保持三处一致：
- 代码中
MDC.put("xxx", ...)的 key - 日志配置（logback.xml / log4j2.xml）中
%X{xxx}的字段名 - 如果接入 ARMS/SkyWalking，还需确认探针使用的标准 key（如
EagleEye-TraceID）
例如 Logback 配置：<pattern>[%d] [%X{TID}] [%p] %m%n</pattern>
