Scoped Values 的作用域生命周期强制依赖 try-with-resources 机制保障自动释放，必须通过 Scope.open() 返回的 AutoCloseable 实例配合 try (var scope = Scope.open()) { ... } 使用，不可手动开启/关闭；嵌套作用域按声明逆序关闭，确保值可见性与状态隔离；脱离该机制将导致 IllegalStateException 或绑定失效；与 StructuredTaskScope 协同时，支持跨虚拟线程上下文继承与自动清理。
Scoped Values 的作用域生命周期完全依赖 try-with-resources 机制来保障自动释放，这不是可选项，而是强制设计约束。
ScopedValue 必须配合 try-with-resources 使用
ScopedValue 本身不提供“手动开启/关闭”接口。它的作用域由 Scope.open() 返回的 AutoCloseable 实例定义，而该实例只能通过 try-with-resources 正确管理：
- 必须写成
try (var scope = Scope.open()) { ... }形式，不能只声明不进入作用域 - 若用传统 try-catch-finally 手动调用
scope.close()，虽语法可行，但违背设计初衷，且易遗漏异常路径下的关闭逻辑 - JVM 保证：无论作用域内代码正常结束还是抛出异常，
scope.close()都会被调用，从而触发绑定值的即时清理
作用域嵌套与资源释放顺序
多个 ScopedValue 可在同一 try-with-resources 中组合使用，其绑定行为遵循词法嵌套和资源关闭逆序原则：
- 每个
ScopedValue.where(key, value).run(...)内部会隐式创建新作用域，但更推荐显式用Scope.open()统一管理 - 若在同一个 try 块中开启多个作用域（例如嵌套 try），外层作用域先关闭，内层后关闭；值的可见性严格按嵌套层级生效
- 资源关闭时，JVM 按声明逆序调用
close()，确保子作用域先退出、父作用域后退出，避免状态污染
常见误用：脱离 try-with-resources 的后果
一旦绕过 try-with-resources，ScopedValue 就失去作用域边界控制能力，导致行为失效或运行时异常：
立即学习“Java免费学习笔记（深入）”；
- 直接调用
ScopedValue.newInstance()后尝试set()→ 抛IllegalStateException: not in scope - 把
Scope.open()结果赋给字段或长期持有 → 编译不报错，但值无法被任何ScopedValue.get()读取，始终返回 null - 在 Spring Bean 初始化块、静态代码块中提前绑定 → 因无执行上下文，绑定失败或被忽略
与 StructuredTaskScope 协同工作
当 ScopedValue 与结构化并发搭配时，try-with-resources 不仅管理单线程作用域，还支撑跨虚拟线程的上下文继承：
- 父任务中用 try (var scope = Scope.open()) 开启作用域并绑定值
- 子任务在
StructuredTaskScope.fork()内执行时，自动继承父作用域中的 ScopedValue 绑定（无需额外 set） - 子任务结束后，其对应作用域随
scope.close()自动释放，不干扰父作用域或其他子任务 - 整个结构化任务块仍需包裹在 try-with-resources 中，形成双重保障：作用域 + 并发生命周期统一管理
