InheritableThreadLocal仅在new Thread()或SimpleAsyncTaskExecutor等新建线程场景下自动生效，通过Thread.init()一次性浅拷贝父线程快照；在线程池、CompletableFuture、@Async等复用线程场景中完全失效，必须手动捕获-设置-清理上下文，否则将导致traceId错乱等脏数据问题。
InheritableThreadLocal 能让子线程在创建时拿到父线程的上下文快照，但“能传”不等于“总能安全传”。它只在 new Thread() 构造那一刻触发一次浅拷贝，对线程池、CompletableFuture、@Async 等复用线程的场景完全无效——这不是配置问题，而是设计机制决定的。真正安全传递，关键在于理解它的生效边界，并在失效场景中主动补位。
明确 InheritableThreadLocal 的生效前提
它只在以下情况自动生效：
-
显式 new Thread(runnable).start()：此时
Thread.init()被调用，父线程的inheritableThreadLocals字段被完整复制 - SimpleAsyncTaskExecutor（Spring）：每次执行都新建线程，满足 init 条件
-
值是创建时的快照，不可实时同步：父线程后续
set()，子线程看不到；子线程再开子线程，第二层不会自动继承
线程池场景必须手动包装 Runnable/Callable
ThreadPoolExecutor、ForkJoinPool、@Async 默认线程池等都不走 init()，必须自己完成“捕获 → 设置 → 清理”闭环：
- 在提交任务前，用
get()显式读取每个关键InheritableThreadLocal的当前值（如traceId.get()、userId.get()） - 把值作为闭包变量传入任务，在
run()或call()开头立即set()回去 -
必须在 finally 块中调用
remove()，否则该线程被复用时会携带旧值，造成上下文污染（比如 traceId 错乱）
Spring @Async 场景下的推荐做法
不要依赖默认配置，而是自定义异步执行器：
- 实现
AsyncConfigurer，重写getAsyncExecutor() - 返回一个包装了原
ThreadPoolTaskExecutor的代理，对所有submit()、execute()方法做Runnable/Callable包装 - 可复用 Spring 提供的
ConcurrentTaskExecutor或直接继承ThreadPoolTaskExecutor，重写decorateTask()钩子
是否该换 TransmittableThreadLocal（TTL）？
TTL 是为解决线程池断链而生的工业级方案，但需注意落地条件：
- 必须用
TtlExecutors.getTtlExecutorService(pool)包装线程池，裸用Executors.newFixedThreadPool()依然无效 - 它通过 Runnable 装饰或字节码增强实现「捕获-重放」，对 Netty、Reactor 等非标准调度仍需额外适配
- 若项目已稳定、异步路径清晰，手动包装 Runnable 更轻量、更可控、更易调试
