InheritableThreadLocal在ForkJoinPool中完全失效，因其仅在线程创建时复制上下文，而ForkJoinPool复用长期存活的工作线程，任务被动态窃取到不同线程执行，无法触发继承逻辑，导致get()几乎总返回null；必须改用TransmittableThreadLocal通过任务提交时快照、执行前回放机制解决。
工作窃取（Work-Stealing）线程池（如 ForkJoinPool）在微服务中常被 Spring、CompletableFuture 或框架底层隐式使用，但它会复用线程、动态调度任务，导致 ThreadLocal 上下文在任务迁移时“凭空消失”——这不是偶发 Bug，而是设计使然。关键在于：ThreadLocal 绑定的是**线程实例**，而工作窃取会让同一个任务在不同线程上执行，原线程的 ThreadLocal 值根本不会自动带过去。
为什么 InheritableThreadLocal 在 ForkJoinPool 中完全失效
InheritableThreadLocal 只在子线程创建瞬间复制父线程值，而 ForkJoinPool 的工作线程是长期存活、反复复用的。任务从主线程提交到 ForkJoinPool 后，可能被任意空闲工作线程“偷走”，该线程早已运行过其他任务，其 ThreadLocalMap 里没有你的上下文，也不会触发继承逻辑。实测中，即使设置 InheritableThreadLocal，ForkJoinPool 中的 get() 也几乎总是 null。
推荐方案：优先使用 TransmittableThreadLocal（TTL）
TTL 是阿里开源的工业级解决方案，专为解决线程池场景设计，对 ForkJoinPool、CompletableFuture、自定义线程池均有效。它不依赖线程创建时机，而是通过包装 Runnable/Callable，在任务提交时捕获上下文，执行前回放，执行后还原：
- 引入依赖：
<dependency><groupId>com.alibaba</groupId><artifactId>transmittable-thread-local</artifactId><version>3.1.2</version></dependency> - 将普通 ThreadLocal 替换为
TransmittableThreadLocal<String> traceId = new TransmittableThreadLocal<>(); - 提交异步任务时必须用 TTL 包装：
forkJoinPool.submit(TtlRunnable.get(() -> { System.out.println(traceId.get()); })); - CompletableFuture 也需包装：
CompletableFuture.supplyAsync(TtlSupplier.get(() -> doSomething()), forkJoinPool);
补充策略：避免在 ForkJoinPool 中强依赖 ThreadLocal
若无法统一接入 TTL（如第三方 SDK 内部硬编码 ThreadLocal），可考虑以下降级手段：
- 显式透传：把关键上下文（如 traceId、tenantId）作为参数传入异步方法，而不是从 ThreadLocal 读取
- 改用普通线程池：对上下文敏感的任务，明确指定
Executors.newCachedThreadPool()或自定义线程池，并配合 TTL 使用 - 禁用 ForkJoinPool 的默认行为：Spring Boot 2.6+ 可配置
spring.task.execution.forkjoinpool.enabled=false，让 @Async 默认走 ThreadPoolTaskExecutor
特别注意：CompletableFuture 的隐藏陷阱
即使用了 TTL，CompletableFuture.runAsync(Runnable) 若未指定 Executor，默认使用 ForkJoinPool.commonPool() —— 这个公共池无法被 TTL 安全增强（因无法控制其线程生命周期）。务必显式传入已包装的 Executor：
- 错误写法：
CompletableFuture.runAsync(() -> process());（走 commonPool，TTL 失效） - 正确写法：
CompletableFuture.runAsync(TtlRunnable.get(() -> process()), customExecutor);
