TTL专为线程池复用场景设计，不适用于new Thread；其依赖capture/replay/restore任务级快照机制，而new Thread无此介入点，此时退化为InheritableThreadLocal的浅拷贝行为。
这个问题其实有点绕——TransmittableThreadLocal（TTL）本身根本不是为“直接 new Thread”设计的，它专治线程池复用场景下的上下文丢失。所以如果你在用 new Thread()，却还指望 TTL 自动传递上下文，那不是“踩坑”，而是用错了工具。
为什么 new Thread 时 TTL 看似“失效”？
因为 TTL 的核心机制是“任务级快照”，不是“线程级继承”。它依赖两个关键动作：
- 任务提交时调用
Transmitter.capture()捕获当前线程的 TTL 值 - 任务执行前通过
replay()注入目标线程，执行后用restore()清理
而 new Thread(runnable).start() 是纯 JDK 原生行为，不经过任何 TTL 的任务包装或线程池装饰，TTL 完全没机会介入。此时它退化为普通 InheritableThreadLocal 的行为：仅在线程创建瞬间浅拷贝，且无法应对后续多次 set/remove 场景。
正确做法：别混用模型，按场景选方案
如果你确实需要手动创建新线程（非线程池），就该回归 InheritableThreadLocal + 显式清理的组合：
- 声明用
new InheritableThreadLocal()，不是 TTL - 子线程内使用完立即
remove()，避免污染 - 若需跨多层嵌套线程（比如子线程再启孙线程），可封装一个带自动 remove 的工具方法
如果本意是“想在线程池里安全传上下文”，那就必须走 TTL 正规路径
漏掉任一环节都会导致丢失：
- 上下文变量必须声明为
new TransmittableThreadLocal() - 线程池必须用
TtlExecutors.getTtlExecutorService(executor)包装 - 提交任务时推荐统一用
TtlRunnable.get(runnable)或TtlCallable.get(callable)包装（尤其在 Spring @Async、CompletableFuture 等间接提交场景下）
特别注意那些“看似没 new Thread，实则暗藏线程切换”的地方
比如：
-
CompletableFuture.supplyAsync(..., executor)—— 必须确保executor是 TTL 包装过的 - Spring 的
@Async方法 —— 对应的TaskExecutorBean 需提前用TtlExecutors装饰 - ForkJoinPool.commonPool() —— 可用
TtlForkJoinPool替代
这些都不是“new Thread”，但都属于线程复用模型，正是 TTL 最擅长的战场。
