ScopedValue 的不可变性指绑定后值本身不可修改，仅支持只读访问；它将值直接存入虚拟线程栈帧，避免哈希查找，性能达 ThreadLocal 的 5 倍；适用于短生命周期、只读上下文（如请求 ID），不适用于可变状态或长生命周期资源。
ScopedValue 的不可变性到底意味着什么
它不是“不能重新绑定”，而是“绑定后无法修改值本身”。ScopedValue.where() 传进去的值，一旦进入作用域，所有 get() 返回的都是同一个不可变对象——你没法调用 set()、update() 或任何会改变其状态的方法（比如 StringBuilder.append()），因为根本没提供这类接口。
- 常见错误现象：试图在作用域内对
ScopedValue<string></string>的值做+=操作，结果发现原值没变，或误以为“改了”其实是新建了字符串对象——这恰恰是设计本意 - 使用场景：适合传递请求 ID、用户身份、租户标识、追踪标记等只读上下文；不适合存需要累加的日志缓冲区或计数器
- 为什么这样做：避免多层调用中某处意外篡改上下文，导致下游逻辑拿到脏数据；也不用担心并发线程看到“半更新”状态
为什么在虚拟线程里 ScopedValue 比 ThreadLocal 快 5 倍
关键不在“算法快”，而在“不存堆上、不查哈希表、不依赖线程字段”。ScopedValue 的值直接压入当前虚拟线程的调用栈帧，访问时就像读一个局部变量；而 ThreadLocal 每次 get() 都要从线程对象的 threadLocals 字段里查 ThreadLocalMap，还要处理哈希冲突和扩容。
- 性能影响：实测
ScopedValue.get()约3ns，ThreadLocal.get()约15ns；当单个请求涉及几十次上下文读取（如日志埋点、权限校验链），差距立刻放大 - 兼容性注意：只有 JDK 21+ 默认启用（JEP 429），且需运行在支持虚拟线程的模式下（
--enable-preview在 JDK 21–22，JDK 23+ 已转正） - 容易踩的坑：用
ThreadLocal的惯性思维去“复用”同一个ScopedValue实例跨多个不相关作用域——不行，每次where().run()是独立绑定，旧绑定已销毁
什么时候不该用 ScopedValue 替代 ThreadLocal
不是所有“线程局部”需求都适合换成 ScopedValue。它的强项是短生命周期、结构化、只读的上下文共享；短板是缺乏动态生命周期管理和可变状态支持。
- 常见错误现象：把数据库连接、HTTP 客户端实例塞进
ScopedValue，结果发现每次run()结束就丢了引用，连接无法复用 - 使用场景限制：若你需要在整个请求处理周期中“懒初始化 + 多次写入 + 跨异步回调保持”，
ScopedValue不行，得结合StructuredTaskScope或退回到InheritableThreadLocal（但要小心内存泄漏） - 参数差异：
ThreadLocal支持initialValue()和remove()；ScopedValue只有of()和where().run()/call()，没有清理钩子——它压根不需要
父子虚拟线程自动继承是怎么工作的
不是复制，也不是反射读取父线程字段，而是 JVM 在调度子虚拟线程时，把当前作用域栈帧里的 ScopedValue 绑定记录“透传”过去。子线程一启动，就能直接 get() 到父作用域里绑的值，且仍是同一份不可变对象。
- 使用场景：Web 请求中派生出多个并行子任务（如查用户、查订单、查积分），无需手动把
requestId当参数层层传递 - 容易踩的坑：在
ExecutorService.submit()提交的Runnable中直接访问ScopedValue.get()——失败，因为该任务脱离了原始作用域；必须用ScopedValue.where().run()显式包裹 - 性能提示：继承本身无额外开销，但若作用域嵌套过深（比如 10 层
where().run()套娃），栈帧管理成本会上升，建议控制在 3–5 层内
where().run()，而是判断“这个值到底该不该进作用域”——它得是逻辑上天然属于某一段执行流的上下文，而不是为了图省事把所有线程局部变量一股脑搬进去。 
