结构化并发的核心是让任务“生得清楚、死得明白”，通过作用域统一管理变量与任务生命周期，确保启动、执行、异常、取消、清理全过程严格绑定，杜绝资源泄漏与状态漂移。
结构化并发的核心，不是让任务跑得更快，而是让任务“生得清楚、死得明白”。它把多任务的变量生命周期统一收束到一个作用域内——变量（包括任务句柄、结果引用、上下文状态）不再随线程或协程自由漂移，而是与作用域的进入和退出严格同步。
作用域即生命周期边界
在结构化并发中，“作用域”不是语法糖，而是资源归属的法律声明。Java 的 StructuredTaskScope、Kotlin 的 CoroutineScope、Go 的 errgroup 或 Rust 的 ScopedTask 都强制要求：所有子任务必须在此作用域内启动；所有任务句柄、返回值、异常对象，其有效生命周期不得超过该作用域的 try-with-resources 块、runBlocking 调用或 WithCancel 上下文的生存期。
- 超出作用域访问
Future.get()或resultNow()会抛出IllegalStateException，而非静默返回陈旧值 - 作用域退出时，未完成的任务自动中断，其持有的栈变量、闭包捕获值、本地缓冲区等一并失效
- 编译器/运行时可据此做静态检查或运行时防护，比如禁止将
scope.fork()返回的Future存入全局 map
变量绑定遵循树形继承规则
每个任务创建时，不仅继承父作用域的取消信号和超时上下文，也继承其变量可见性边界。这意味着：闭包中引用的局部变量、函数参数、临时对象，其生命周期由最外层结构化作用域兜底保障，而非由线程调度或 GC 决定。
- Java 示例中，
fetchUser()和countOrders()里访问的userId参数，只要被scope.fork()捕获，就保证活到scope.join()结束 - Kotlin 中，
launch { delay(1000); println(data) }里的data不会因协程挂起而被提前回收，因为CoroutineScope已将其纳入结构化内存图谱 - 这种绑定不是靠强引用计数，而是靠作用域退出时的统一清理协议，避免循环引用导致的泄漏
异常与取消触发变量集体失效
结构化并发将“失败”定义为作用域级事件。任一子任务抛出未捕获异常，或父作用域主动调用 shutdown() / cancel()，会立即触发整个作用域内所有活跃变量的状态重置：
- 所有
Future进入CANCELLED或FAILED状态，后续get()抛出对应异常 - 协程中正在等待的
suspend fun立即恢复并抛出CancellationException，其挂起点保存的局部变量被标记为不可访问 - 上下文携带的
ThreadLocal、RequestScope等绑定数据，在作用域关闭时同步清除，杜绝跨任务污染
显式变量管理替代隐式线程局部存储
传统并发依赖 ThreadLocal 或手动传参来维持任务上下文，容易遗漏或错配。结构化并发则将变量注入变成作用域初始化的一部分：
- Java 可通过自定义
StructuredTaskScope子类，在openSubscope()中预置MDC、TracingContext等 - Go 使用
context.WithValue(ctx, key, val)创建新上下文，所有基于它的 goroutine 共享同一份键值对，且随上下文销毁自动失效 - 这种机制让“请求级变量”真正成为结构化单元的一等公民，而不是游离于线程之上的脆弱附着物
