不自动。StructuredTaskScope不注入中断，仅提供结构化生命周期管理；子任务必须显式检查Thread.interrupted()或处理InterruptedException才能响应中断。
Java 21中StructuredTaskScope的中断传播是否自动生效？
不自动。即使父任务被中断，子任务默认不会收到中断信号——除非你显式调用 scope.close() 或 scope.join() 后发生异常，且子任务本身检查了 Thread.interrupted() 或响应了 InterruptedException。
根本原因在于：Java 21 的 StructuredTaskScope 本身不注入中断，它只提供作用域边界和结构化生命周期管理。中断传播是协作式的，不是抢占式的。
- 子任务若用
Thread.sleep()、BlockingQueue.take()等阻塞调用，会抛出InterruptedException并自动清除中断状态，此时需在 catch 块里重新设置Thread.currentThread().interrupt() - 纯计算型子任务（比如 while 循环累加）必须主动轮询
Thread.currentThread().isInterrupted()，否则永远收不到中断 -
StructuredTaskScope.ShutdownOnFailure和ShutdownOnSuccess在子任务异常/完成时会尝试关闭作用域，但不会主动中断仍在运行的子线程
如何让子任务真正响应父作用域的中断？
关键是在子任务逻辑中把中断检查和清理动作“焊死”进执行路径，不能依赖框架代劳。
常见错误是写成这样：
立即学习“Java免费学习笔记（深入）”；
scope.fork(() -> {
while (someCondition) {
doWork();
}
return result;
});
这段代码完全无视中断。正确做法是：
- 所有阻塞调用外层包裹 try-catch，并在 catch 中调用
Thread.currentThread().interrupt() - 循环体开头插入
if (Thread.currentThread().isInterrupted()) throw new InterruptedException(); - 若子任务使用
ExecutorService提交内部任务，注意该 service 本身不继承父作用域中断——得手动传入ThreadFactory绑定中断上下文
StructuredTaskScope.join() 抛出 InterruptedException 怎么处理？
这不是子任务出错，而是作用域等待过程被外部中断了。此时子任务可能还在跑，也可能已结束，状态不确定。
典型误操作：捕获 InterruptedException 后直接吞掉或忽略，导致后续逻辑误判子任务已完成。
- 必须在 catch 块里立即调用
scope.close()，强制终止作用域并尝试中断所有活跃子任务（前提是子任务已正确响应中断） - 不要在
join()外再写一层scope.shutdown()——重复调用close()会抛IllegalStateException - 如果需要超时控制，用
scope.joinUntil(Instant.now().plusSeconds(5))，它返回false表示超时，此时也应调用scope.close()
为什么用 shutdownOnFailure 却没中断其他子任务？
因为 ShutdownOnFailure 只保证“当任一子任务抛出未捕获异常时，停止接收新任务并等待其余子任务自然结束”，它不调用 interrupt()。
这个设计很反直觉，但符合结构化并发的保守原则：避免强制中断引发资源泄漏或状态不一致。
- 若要实现“一个失败就全停”，必须在子任务里统一约定：一旦检测到作用域已关闭（例如通过共享
AtomicBoolean），主动退出 - 更稳妥的方式是配合
StructuredTaskScope的owner参数，用Thread.currentThread().getOwner()获取当前作用域引用，再监听其状态变化（需自行封装） - 别指望
shutdownOnFailure替你做中断决策——它只管生命周期，不管线程信号
结构化并发真正难的不是写对语法，而是把中断语义像呼吸一样嵌进每一段子任务逻辑里。漏掉一次 isInterrupted() 检查，整个作用域的取消行为就可能失效。
