InheritableThreadLocal在异步线程池中无法透传上下文，根本原因是线程复用绕过Thread.init()导致继承逻辑不触发；childValue()仅初始化调用一次，remove()不及时会引发上下文污染和内存泄漏。
InheritableThreadLocal 在异步线程池中无法稳定透传用户上下文，根本原因不是“没继承”，而是它压根没机会继承——线程池复用线程绕过了继承触发点。
继承只发生在 new Thread() 的那一刻
InheritableThreadLocal 的值复制逻辑藏在 Thread.init() 里，仅当 JVM 创建全新线程时调用一次。线程池中的工作线程是提前创建、长期存活的，后续 submit() 或 execute() 提交的任务，只是把 Runnable 丢进队列，由已有线程直接 run()，全程不走 Thread 构造流程，也就不会触发任何继承行为。
- 第一次任务执行时，可能偶然读到父线程 set 的值（因线程刚初始化，inheritableThreadLocals 还是空的，但某些 JDK 版本或特定时机下会残留）
- 第二次任务执行时，该线程可能还带着上一个请求的 userId、tenantId、traceId 等残留值
- 第三次任务执行时，若前序任务未 remove()，就可能污染当前请求的上下文
childValue() 不是实时同步钩子
很多人误以为重写 childValue() 就能实现动态透传。实际上它只被 init() 调用一次，且仅用于初始化子线程的初始值。任务执行中途修改了主线程的 InheritableThreadLocal 值，子线程完全感知不到；反之，子线程自己 set() 后也不影响主线程。
- filter 中修改了 UserContext，下游异步任务仍拿到旧快照
- 多个并行异步任务共享同一工作线程时，彼此 set()/get() 相互覆盖，结果不可预测
remove() 不及时 = 上下文“串货” + 内存泄漏
线程池线程生命周期远长于单次请求。如果每次任务结束时不显式调用 remove()，UserContext 对象就会一直挂在该线程的 inheritableThreadLocals Map 里：
- 下一个请求复用该线程，可能误读到前一个用户的 userId，引发权限越界或日志错乱
- UserContext 是强引用，若含大对象或未清理的 IO 资源，会持续占用堆内存
- HeapDump 中常见特征：大量 UserContext 实例被 Thread 对象持有，GC 无法回收
手动透传成本高且易遗漏
有人尝试在提交任务前手动 get() 值、封装进 Runnable、执行前 set()、finally 中 remove()。这看似可行，但隐患明显：
- 每个 InheritableThreadLocal 变量都要单独处理，无通用反射方案（字段可见性、泛型擦除、深拷贝逻辑均难统一）
- 一旦漏掉某个 remove()，问题立即复现；漏掉某处包装，上下文就断档
- 第三方 SDK 内部使用的线程池（如 Dubbo、RocketMQ 回调线程）无法干预，彻底失控
