题干与适用场景
面试官给出一个请求处理函数，它需要并行执行三个彼此相关的子任务：读取用户资料、读取订单和生成推荐。客户端断开、任一关键子任务失败或总截止时间到达时，系统不能留下继续运行的孤儿任务。回答要解释结构化并发的核心思想，再说明怎样把它落到不同语言的任务组、协程作用域或结构化任务范围中。
这道题适合中高级后端、平台、移动端和跨语言基础设施岗位。重点不是背某个 API，而是能否把任务的进入点、退出点、失败策略和资源归属说清楚。
面试官考察点
面试官会看你是否把并发任务视为父任务的一部分，而不是把工作扔进一个全局线程池就返回。强回答会说明子任务不能越过父作用域存活，父任务取消如何递归传播，失败是快速失败还是允许部分结果，以及如何保证 join、关闭和指标记录都发生在边界内。
普通回答只说“用 async/await 并行执行”。高质量回答会把结构化并发与非结构化 Future、全局后台任务区分开，明确哪些工作属于请求生命周期，哪些工作应该转成独立队列或持久化工作流。
回答前需要澄清的问题
- 三个子任务是否都必须成功？用户资料和订单失败时，推荐是否仍有价值？
- 截止时间是客户端请求的硬 deadline，还是服务端可以继续完成的软预算？
- 子任务是否只做可取消的 I/O，还是包含不可中断的外部副作用？
- 客户端断开后，是否允许把结果转入异步通知或后台任务？
- 失败时需要返回一个错误、部分结果，还是可解释的降级状态？
这些答案会改变作用域边界：请求内的短任务留在父作用域，跨请求继续运行的工作必须显式转移所有权，不能偷偷逃逸。
30 秒回答框架
我先把一次请求定义为父任务，三个并行读取是它的子任务；父任务只有在子任务完成、失败或取消处理完后才能退出。关键资料失败时快速取消兄弟任务，推荐失败则返回明确的降级结果。客户端断开和 deadline 都向下传播取消信号，子任务在 finally 或等价清理块释放连接和句柄。若工作必须在请求结束后继续，我会把它写入持久队列，建立新的生命周期，而不是让一个后台 Future 脱离作用域。最后用取消、超时、部分失败和泄漏指标做故障测试。
分步骤深入解答
第一步：先画出任务树
把请求处理函数作为根节点，资料、订单和推荐是它的直接子节点。子任务继承父任务的 deadline、追踪上下文和取消信号。父任务负责等待结果、合并错误并关闭作用域；子任务不能把未完成的工作交给全局执行器后就让父函数返回。
这棵树提供一个可检查的不变量：父任务退出时，所有子任务都已完成、取消或被明确转移给另一个有记录的所有者。没有这个不变量，线程泄漏、重复写入和不可解释的尾延迟都会被隐藏。
第二步：选择失败和部分结果策略
先按业务价值分类。用户资料和订单是结算页面的必要数据，任一失败就取消兄弟任务并返回可重试错误；推荐是增强信息，失败时记录原因并返回没有推荐的响应。不要让一个低价值任务的失败拖垮整个请求，也不要把关键数据的缺失伪装成空对象。
伪代码可以表达策略，但不绑定语言：
within request_scope(deadline):
profile = child(fetch_profile)
orders = child(fetch_orders)
recommendations = child(fetch_recommendations)
wait(profile, orders)
if profile.failed or orders.failed:
cancel_all_children()
return retryable_error
return compose(profile, orders, recommendations.or_empty)第三步：让取消真正到达资源边界
取消不是把一个布尔值写进任务对象就结束。网络客户端、数据库驱动和文件读取都要检查取消信号；等待操作需要可中断；重试循环必须在下一次尝试前重新检查 deadline。对于无法撤销的外部副作用，例如已经提交的支付或发出的邮件，取消只能阻止后续步骤，不能声称回滚已经发生的事实。
客户端断开时，入口层取消根任务。根任务再向子任务传播，子任务在清理块中关闭响应体、连接、订阅和临时文件。清理动作本身也要有上限，避免“等待清理”永远阻塞请求收尾。
第四步：区分超时、取消与失败
超时是预算耗尽，取消是上游明确不再需要结果，失败是任务无法完成。三者可能同时出现，但日志和用户状态不能混成一个 500。记录原始原因、触发者和任务路径；对客户端断开通常不重试，对下游超时可以按剩余预算决定是否一次短重试，对业务错误则交给明确的降级策略。
不要把 sleep 或盲目重试放在作用域外。它们会消耗已经过期的预算，并在父任务返回后继续制造负载。
第五步：验证结构是否真的被保持
测试父任务正常完成、关键子任务失败、可选子任务失败、父任务取消、deadline 到期和子任务启动前取消。每次测试都检查：活动子任务最终回到零；下游连接关闭；追踪中能看到父子关系；没有重复副作用；错误分类与用户状态一致。
对运行时指标记录活动任务数、取消传播延迟、deadline 超时率、子任务异常、清理耗时、被取消后仍运行的任务数和每个请求的最大扇出。只有“请求返回成功”而没有这些指标，不能证明结构化并发生效。
高质量示范回答
“我会把一次请求当作父任务，把三个读取操作放进同一个受 deadline 约束的作用域。父任务负责创建、等待和关闭子任务，子任务的生命周期不能超过这个作用域。用户资料和订单是关键依赖，任一失败就取消兄弟任务并返回可重试错误；推荐是可选依赖，失败时返回明确的空推荐状态，同时记录降级原因。
客户端断开、父任务超时或上游取消都会沿任务树向下传播。每个 I/O 调用都使用可取消接口，重试前检查剩余预算，清理块关闭连接和订阅。已经发生的外部副作用不假装可以回滚；如果必须在请求结束后继续，我会先写入持久队列，再由消费者开启新的任务树。
我会用故障注入验证关键失败、可选失败、取消竞态和清理超时，并观察活动任务、取消延迟、泄漏数和父子追踪。这样回答的重点是生命周期和所有权，不依赖 Java、Kotlin 或 Swift 的某个具体 API。”
常见错误
- 把结构化并发等同于并行执行 → 只描述同时启动任务，遗漏父子生命周期 → 画出作用域、join、取消和关闭边界。
- 用全局线程池提交后立即返回 → 父请求结束后任务仍可能访问已失效资源 → 让任务留在请求作用域，或显式转移到持久队列。
- 把取消当成强制杀死 → 外部副作用可能已经完成，资源也未必自动释放 → 声明合作式取消、不可撤销操作和清理责任。
- 所有失败都返回空结果 → 关键数据缺失被伪装，调用方无法区分降级和错误 → 按业务关键性定义快速失败与部分结果。
- 只测成功路径 → 取消竞态和孤儿任务不会暴露 → 注入断开、超时、兄弟失败和重复取消，并检查活动任务最终归零。
追问及应对
追问一：如果推荐生成需要几秒，用户请求已经结束，怎么办？
先确认用户是否仍需要这项结果。若页面只在当前请求展示，推荐必须随父任务取消；若业务要异步生成，先把输入和幂等键写入持久队列，再由消费者创建新的作用域。新的消费者拥有独立 deadline、重试和告警，不能借用已经结束的请求上下文。
追问二：一个子任务失败，为什么不能让其他任务继续跑完再决定？
可以，但要先证明剩余工作有价值且不会超过预算。关键数据失败后继续查询订单通常只会浪费连接和下游容量；对可独立缓存的资料或审计证据，继续完成可能合理。回答应给出取消策略的条件，而不是把快速失败当成永远正确。
追问三：取消信号已经发出，但数据库查询仍在运行，怎么处理？
检查驱动是否支持取消和连接归还；在驱动不支持时设置独立的查询超时、隔离连接池和结果丢弃保护，避免把取消延迟伪装成已停止。记录从取消到资源释放的时间，超过阈值就降级、隔离或告警。不可中断的查询不能继续占用请求级配额。
追问四：结构化并发是否取代所有线程池和消息队列？
不取代。它适合有明确父子关系、需要共同取消和共同收尾的短生命周期工作。跨请求任务、定时任务、需要持久重试的工作仍应使用队列或工作流；共享线程池可以作为执行资源，但提交任务的作用域必须定义谁等待、谁取消和谁负责结果。