ScopedValue 比 ThreadLocal 更轻量，因其不绑定线程生命周期，仅在代码块作用域内传递只读值，避免虚拟线程频繁启停导致的 map 扩容、清理开销及内存泄漏风险。
ScopedValue 在虚拟线程里为什么比 ThreadLocal 更轻量
因为 ScopedValue 不绑定线程生命周期，只在代码块作用域内传递值，虚拟线程频繁启停时不会触发 ThreadLocal 的 map 扩容、清理或内存泄漏风险。
常见错误现象：用 ThreadLocal 存用户上下文，在高并发虚拟线程场景下 GC 压力陡增，甚至出现 OutOfMemoryError: Metaspace（因大量线程局部类加载器残留）。
-
ThreadLocal每个线程独占一份副本，10 万个虚拟线程 ≈ 10 万份拷贝；ScopedValue是共享引用，只传一次 -
ScopedValue不依赖线程状态，可在ForkJoinPool、Executors.newVirtualThreadPerTaskExecutor()等任意执行器中无缝工作 - 不支持继承（即子虚拟线程默认拿不到父作用域的值），这点和
InheritableThreadLocal有本质区别
怎么声明和绑定 ScopedValue（Java 21+）
必须用 ScopedValue.<em>construct()</em> 创建，且只能通过 ScopedValue.where() + run() 或 call() 注入作用域 —— 没有 set/get 接口，不能中途修改。
使用场景：请求链路中的 traceId、租户 ID、认证主体等只读上下文数据。
- 声明必须是
static final，否则编译报错：ScopedValue要求编译期可确定 - 值类型需是不可变对象（如
String、record），否则运行时可能被意外修改 - 不能在
ScopedValue.where()外部访问get()，会抛IllegalStateException: No value bound
示例：
static final ScopedValue<String> TRACE_ID = ScopedValue.construct();
...
ScopedValue.where(TRACE_ID, "req-abc123").run(() -> {
System.out.println(TRACE_ID.get()); // 正确
});
ScopedValue 和 StructuredTaskScope 结合使用的坑
虚拟线程常配合 StructuredTaskScope 实现并行子任务，但 ScopedValue 默认不跨子任务传播 —— 这不是 bug，是设计使然。
错误现象：主任务绑定了 TRACE_ID，子任务里 TRACE_ID.get() 抛异常，日志链路断掉。
- 必须显式调用
scope.fork(() -> ScopedValue.where(...).run(...))，不能指望自动继承 - 如果子任务也用
StructuredTaskScope嵌套，每一层都要手动 bind，没有“作用域继承”机制 - 性能影响：每次
where().run()有微小开销（约几十纳秒），高频嵌套建议复用同一ScopedValue实例，别反复 construct
哪些情况还是得退回 ThreadLocal
当需要在线程整个生命周期内维持可变状态（比如缓存计算中间结果、统计计数器），或者必须支持子线程自动继承时，ScopedValue 就不合适了。
典型兼容性问题：老框架（如 Spring Security 的 SecurityContextHolder）底层强依赖 ThreadLocal，强行替换会导致认证上下文丢失。
-
ThreadLocal支持remove()主动清理，ScopedValue完全依赖作用域结束自动回收，无法干预 - 调试困难：IDE 无法在断点中直接 inspect
ScopedValue当前值，必须靠日志或包装逻辑输出 - Java 21 是最小版本要求，且需启动参数
--enable-preview，生产环境灰度要小心 classpath 冲突
真正难处理的，是那些既想享受虚拟线程密度、又绕不开旧线程绑定模型的中间件集成场景 —— 这时候往往得写一层适配桥接，而不是非此即彼地选一个。
