childValue是透传TraceID的关键入口，因为InheritableThreadLocal默认仅拷贝父线程value引用，而TraceID常封装于可变对象中；重写childValue可实现深拷贝或新建不可变实例，确保子线程初始值安全独立，但仅对new Thread()等新建线程场景生效，复用型线程池需配合TaskDecorator等手动透传。
为什么 childValue 是透传 TraceID 的关键入口
因为 InheritableThreadLocal 默认只拷贝父线程的 value 引用，而 TraceID 通常封装在可变对象（比如 TraceContext）里——子线程拿到的是同一份引用，一旦修改就会污染父线程。真正安全的透传必须在 fork 子线程时做深拷贝或生成新实例，childValue 就是这个定制点：它在每次 new Thread() 或 ForkJoinPool 创建子任务时被调用，返回值作为子线程的初始值。
如何重写 childValue 实现 TraceID 安全继承
直接继承 InheritableThreadLocal，覆盖 childValue 方法，在其中对原始值做不可变处理或克隆：
private static final InheritableThreadLocal<String> TRACE_ID_HOLDER = new InheritableThreadLocal<>() {
@Override
protected String childValue(String parentValue) {
// 父线程没设 TraceID，子线程也不设
if (parentValue == null) return null;
// 返回新字符串实例，避免共享引用
return new String(parentValue);
}
};
注意：如果 TraceID 存在更复杂的上下文对象（如含 spanId、sampled 标志），则需确保该对象本身不可变，或在 childValue 中调用其 copy() / toImmutable() 方法。
哪些异步场景会触发 childValue？哪些不会？
childValue 只在子线程创建时生效，具体取决于线程复用机制：
-
会触发：
new Thread(runnable).start()、Executors.newCachedThreadPool()（每次新建线程）、ForkJoinTask.fork()（默认使用 ForkJoinPool 的工作线程，但首次 fork 仍走 childValue） -
不会触发：
Executors.newFixedThreadPool(n)复用已有线程；CompletableFuture.supplyAsync(fn, executor)若传入的是复用型线程池（如fixed或cached的 pool），则子任务运行在线程池已有线程上，childValue不会被调用 —— 此时需靠手动get()+set()透传
也就是说，仅靠 childValue 无法覆盖所有异步路径，尤其在主流框架（Spring Boot + @Async、WebFlux、Dubbo）中，线程池复用是常态。
实际项目中容易漏掉的三个坑
很多团队在接入时发现 TraceID 在某些异步分支丢失，往往卡在这几个地方：
- 没意识到
ThreadPoolTaskExecutor（Spring 的@Async底层）默认用LinkedBlockingQueue+ 固定线程数，子任务不触发childValue—— 必须配合TaskDecorator手动 copy 上下文 - 在
childValue里做了耗时操作（如远程调用、日志打印），会拖慢线程创建，甚至引发线程饥饿 - 使用了
TransmittableThreadLocal（阿里 TTL）却误以为它能自动兼容所有线程池 —— 其实也需要显式注册TaskDecorator或包装Executor
最稳的做法不是只押注 childValue，而是把它作为“线程新建”这一特定路径的补充，主逻辑统一走装饰器模式或框架钩子（如 Spring 的 AsyncConfigurer）。TraceID 透传本质是上下文生命周期管理问题，不是单个 API 能兜底的。
