InheritableThreadLocal仅在new Thread()构造时通过Thread.init()触发一次父线程值的浅拷贝，线程池、CompletableFuture、@Async等复用线程场景因不调用init()而无法继承，导致读取旧值而非null；需手动捕获-传递-清理，或改用TtlExecutors包装的TransmittableThreadLocal。
InheritableThreadLocal 能让子线程在创建时拿到父线程的上下文快照，但它只在 new Thread() 这类全新线程构造时生效，对线程池、CompletableFuture、@Async 等复用线程的场景完全无效——这不是配置问题，而是设计机制决定的。
它怎么工作的？只在子线程诞生那一刻“拍照”
InheritableThreadLocal 继承自 ThreadLocal，重写了两个关键方法：
-
getMap(Thread t)：从
t.inheritableThreadLocals而非t.threadLocals读取值 -
createMap(Thread t, T firstValue)：初始化时把值写入
t.inheritableThreadLocals - 真正触发继承的是
Thread.init()—— 仅在 new Thread() 构造时调用一次，把父线程当前所有 InheritableThreadLocal 的get()结果浅拷贝过去
为什么 CompletableFuture 和 @Async 拿不到值？
因为它们不新建线程，而是调度到已存在的线程上执行：
-
CompletableFuture.runAsync()默认走ForkJoinPool.commonPool()，线程被反复复用 -
@Async底层是ThreadPoolExecutor，线程不会重新构造，init()不再触发 - 结果不是 null，而是上一个任务留下的旧值（比如 traceId="req-a" 被 req-b 任务误用），这种“脏上下文”比空值更难排查
在线程池中让它真正起作用的实操方式
不能依赖自动继承，必须手动搬运 + 清理：
- 在提交任务前，捕获父线程中每个关键 InheritableThreadLocal 的当前值（例如
traceId.get()、userId.get()） - 把这些值作为闭包变量传入 Runnable/Callable，在子线程执行前
set()回去 - 务必在
finally块中调用remove()，防止该线程后续被复用时携带残留值 - 如果用了多个 InheritableThreadLocal 实例，每个都要单独做这套操作，没有通用反射方案能安全兜底
要不要换 TransmittableThreadLocal？
TTL 是为解决线程池场景而生的增强方案，但要注意前提：
- 必须用
TtlExecutors.getTtlExecutorService(pool)包装原有线程池，裸用Executors.newFixedThreadPool()依然无效 - 它通过字节码增强或 Runnable 装饰实现「捕获-重放」，对非标准线程启动方式（如 Netty ChannelFuture、Reactor publishOn）仍需额外适配
- 若项目已稳定使用 InheritableThreadLocal 且异步逻辑可控，手动包装 Runnable 是更轻量、更透明的选择
