Swift的TaskGroup让并发任务的编写变得直观，但很多人在处理子任务抛出的错误时，往往会忽略一个关键行为：只要有一个子任务抛出了错误，整个任务组就会立即取消所有尚未完成的子任务，并且这个错误会被直接传播给调用方。这个机制并非偶然，而是由Swift并发的结构化错误模型决定的。理解它的触发条件和取消传播路径，对于编写可靠的异步代码至关重要。
TaskGroup的基本错误模型
在使用withTaskGroup或withThrowingTaskGroup时，错误处理的方式有细微差别。普通的withTaskGroup假设子任务不会抛出错误，因此闭包中的子任务必须自行处理所有错误。而withThrowingTaskGroup则允许子任务抛出错误，但代价是：一旦某个子任务抛出错误，整个组会立刻进入取消状态。来看一个简单的例子：
func fetchAllData() async throws -> [Int] {
try await withThrowingTaskGroup(of: Int.self) { group in
for i in 1...5 {
group.addTask {
if i == 3 {
throw URLError(.badServerResponse)
}
try await Task.sleep(nanoseconds: UInt64(i) * 1_000_000_000)
return i
}
}
var results: [Int] = []
for try await result in group {
results.append(result)
}
return results
}
}
上面的代码中，当i == 3的子任务抛出URLError时，for try await循环会立即收到这个错误并向外传播。与此同时，group内部会向所有仍在执行的子任务发送取消信号。那些正在Task.sleep中的子任务会被唤醒并抛出CancellationError。最终fetchAllData只会抛出URLError，而其他子任务的部分结果不会被返回，因为它们要么被取消，要么还没等到被收集。
这种“快速失败”策略是Swift并发模型的设计选择之一。它保证了调用方能够尽早感知到失败，并且不会继续浪费资源执行已经没有意义的子任务。但这也意味着，如果某些子任务正在执行不可中断的清理工作，或者需要确保所有子任务都完成才能释放资源，那么默认行为可能并不合适。例如在处理文件写入时，如果某个写入失败就取消所有其他写入，可能会导致部分文件已经写入而其他文件尚未写入，留下不一致状态。
取消与传播的底层执行流程
当withThrowingTaskGroup的闭包中有一个子任务抛出错误时，真正触发取消动作的是for try await的迭代过程。这个迭代器在内部调用了group.next()，而group.next()会等待下一个子任务完成。如果有子任务以错误结束，next()会返回这个错误。此时结构化并发的要求是：由于错误已经发生，所有仍在运行的子任务必须被取消，以保证任务组不会悬挂在中间状态。这个取消是隐式的，并不需要开发者手动调用group.cancelAll()。
取消传播的路径大致如下：首先，next()检测到错误后，会通过任务组的内部状态标记所有子任务为已取消。然后每个子任务会收到CancellationError或者通过Task.checkCancellation()抛出取消错误。对于正在执行CPU密集型操作的子任务，SWIFT并发运行时不会强制中断它们，而是将Task.isCancelled设为true，由子任务自行在合适的时机检查取消状态。这意味着，如果某个子任务忽略了取消标志，它会继续执行直到自然结束，这可能导致任务组无法立即退出，但最终for try await循环仍会因为已经收到错误而提前终止。
这里有一个容易混淆的点：withThrowingTaskGroup返回的闭包本身也可以抛出错误。如果闭包在for try await循环之外抛出了错误，同样会触发取消，但这个取消需要在group的范围内手动调用group.cancelAll()吗？实际上不需要。结构化并发规则保证，只要控制流以抛出的方式离开闭包，任务组会自动取消所有剩余子任务。这就是为什么官方文档建议不要依赖group.cancelAll()来清理，除非你需要在子任务之间主动传播取消信号。
实践中的异常处理策略与对比
了解了默认行为后，开发者需要根据场景决定是否修改错误处理策略。如果希望收集所有子任务的错误，而不是在第一个错误出现时就停止，可以采用两种方式。第一种是在子任务内部捕获错误，将错误包装成Result类型返回。例如：
func fetchAllWithResults() async -> [Result<Int, Error>] {
await withTaskGroup(of: Result<Int, Error>.self) { group in
for i in 1...5 {
group.addTask {
do {
let value = try await performRequest(i)
return .success(value)
} catch {
return .failure(error)
}
}
}
var results: [Result<Int, Error>] = []
for await result in group {
results.append(result)
}
return results
}
}
这种做法的好处是子任务不会因为错误而取消整个组，所有的子任务都会执行完毕，最后调用方可以统一处理每个结果。但缺点也很明显：如果某个子任务执行时间很长，即使它已经注定失败，其他子任务也必须等待它完成，无法提前释放资源。这在网络请求较多的情况下会显著增加总耗时和内存占用。
第二种策略是使用withThrowingTaskGroup但手动管理取消逻辑。例如，在第一个错误出现后立即调用group.cancelAll()，然后继续消费剩余子任务的结果或错误，确保清理工作得以完成。示例如下：
func fetchWithCleanup() async throws -> [Int] {
try await withThrowingTaskGroup(of: Int.self) { group in
for i in 1...5 {
group.addTask {
try await performRequest(i)
}
}
var results: [Int] = []
var firstError: Error?
do {
for try await result in group {
results.append(result)
}
} catch {
firstError = error
group.cancelAll()
// 继续消费剩余子任务，但要区分取消错误和真正的业务错误
while let remaining = try? await group.next() {
results.append(remaining)
}
}
if let firstError {
throw firstError
}
return results
}
}
这段代码在捕获到第一个错误后，通过group.cancelAll()通知所有子任务停止工作，但仍然使用try?继续读取group.next()的结果。由于子任务被取消后通常会抛出CancellationError，这些错误会被try?忽略，只有那些在取消前已经完成并返回结果的任务才会被收集。最后，原始错误被重新抛出。这种方式兼顾了快速失败和资源清理，但代码复杂度明显上升，需要开发者清楚地区分取消错误和真正的业务错误，否则可能掩盖实际失败原因。
还有一种更细粒度的做法是使用withTaskGroup的非抛出版本，并在每个子任务内部使用Task.checkCancellation()配合async let的并发错误模式。不过这种方案通常适用于更复杂的依赖关系，对于绝大多数简单的请求聚合场景，直接使用withThrowingTaskGroup的默认行为已经足够，只要在子任务中处理了取消操作即可保证资源正确释放。
值得注意的是，withThrowingTaskGroup的文档中明确提到，如果group.next()返回一个错误，那么所有尚未完成的子任务会在异步函数返回之前被自动取消。这意味着即使不写group.cancelAll()，只需要让错误传播出去，取消就会自动发生。因此上面的fetchWithCleanup示例中，group.cancelAll()其实是冗余的，因为for try await在抛出错误之前已经触发了取消。但显式调用可以增强代码可读性，尤其在闭包内部需要提前取消的场景下。
理解Swift TaskGroup的取消与错误传播机制，不仅能避免写出产生资源竞争或悬挂任务的代码，还能在性能与健壮性之间做出合理权衡。当所有子任务必须全部成功才能继续时，默认的快速失败最合适；当需要容忍部分失败并收集尽可能多的结果时，应该改用Result包装或在子任务内部捕获错误。后一种做法在批量图片下载、多路API探测等场景中非常实用。
Swift TaskGroup异常处理取消传播机制修改时间：2026-09-25 07:09:05