在使用Swift的TaskGroup编写并发任务时，很多精力都会放在任务的分发与结果的收集上，而任务取消后的清理逻辑却常常被忽视。一个典型的问题是：当外层任务被取消、子任务陆续收到取消信号时，写在子任务末尾的清理代码到底运行在哪个执行器上？如果清理逻辑需要访问actor隔离的状态，而它却跑在了协作线程池的某个线程上，就会触发运行时错误或产生数据竞争。本文将围绕这一问题展开分析，并给出可落地的解决方案。
一、理解任务取消的传播机制与执行器归属
TaskGroup的取消是一个自上而下的传播过程。当我们调用group.cancelAll()、外层Task被取消，或者抛出错误触发自动取消时，取消信号会沿着任务树向下传递到每一个子任务。这个信号本身并不会中断已经在执行的代码，它只是设置了一个标志位。子任务中的代码需要主动检查Task.isCancelled或者调用try Task.checkCancellation()来感知取消。
关键点在于：取消信号的传递并不改变任务当前的执行器归属。一个运行在协作线程池上的子任务，被取消后依然在原来的线程上继续执行，直到它遇到下一个 suspension point（挂起点）。只有在挂起点恢复时，Swift运行时才会根据代码的隔离标注重新决定恢复到哪个执行器。这意味着，如果你在try await之后直接写清理代码，这段代码可能还停留在子任务原本的执行环境中，而不是你期望的actor上下文。
看一个典型的反面示例：
func fetchAndClean(_ group: inout TaskGroup<Data>) async throws {
for url in urls {
group.addTask {
let data = try await loadData(from: url)
// 危险：取消抛出后，这里可能不在预期执行器上
await self.cleanupCache(for: url)
return data
}
}
}如果loadData因为取消而抛出CancellationError，子任务直接终止，cleanupCache根本不会执行。即使没有抛出而是正常返回，self如果是actor，await self.cleanupCache会正确切换，但若cleanupCache被标记为nonisolated，清理代码就会在协作线程池上运行。理解这种归属关系是解决线程安全问题的第一步。
二、用defer配合显式执行器切换保证清理逻辑落地
最直接的手段是使用defer保证清理代码无论正常返回还是抛出都会执行，同时在清理逻辑内部显式指定目标执行器。对于需要访问MainActor状态的场景，可以使用MainActor.run或者将清理函数本身标注为@MainActor。
actor ImageCache {
private var cache: [URL: Data] = [:]
@MainActor
func cleanupUIState(for url: URL) {
// 这里保证运行在主线程
progressViews[url]?.removeFromSuperview()
}
}
func processImages(urls: [URL]) async throws {
try await withThrowingTaskGroup(of: Void.self) { group in
for url in urls {
group.addTask {
defer {
// defer中的await是允许的，因为闭包本身是async
await Task { @MainActor in
await self.cache.cleanupUIState(for: url)
}.value
}
guard !Task.isCancelled else { return }
let data = try await loadImage(url)
await self.cache.store(url, data)
}
}
}
}需要注意，defer块里不能直接await（在非async defer语法可用前），所以上面的写法通过创建一个新的Task并指定@MainActor来承载清理调用。这种方式虽然可行，但每次清理都新建Task开销略大。更优雅的替代方案是使用withTaskCancellationHandler，把清理动作注册为取消处理器：
group.addTask {
let handle = Task {
await self.cache.cleanupUIState(for: url)
}
return try await withTaskCancellationHandler {
try await loadImage(url)
} onCancel: {
// 取消发生时立即触发，可在此启动隔离的清理任务
handle.start()
}
}两种方案各有取舍：defer方案覆盖所有退出路径（包括正常完成），而取消处理器方案只在取消时触发，且响应更及时。实际项目中建议组合使用——取消处理器负责及时释放资源，defer负责兜底收尾。
三、结构化并发下的整体收尾：在正确的作用域做汇总清理
除了每个子任务内部的清理，TaskGroup作用域结束后的汇总清理同样重要。一个被广泛认可的模式是：不在子任务里各自清理共享状态，而是让所有子任务只返回结果或错误，把状态修改统一收拢到组作用域外层的隔离上下文中执行。这样天然避免了多线程同时操作共享状态的问题。
@MainActor
final class Downloader {
private var finished: Set<URL> = []
func downloadAll(_ urls: [URL]) async {
let results = await withTaskGroup(of: URL?.self) { group in
for url in urls {
group.addTask {
try? await loadImage(url) != nil ? url : nil
}
}
var collected: [URL] = []
for await url in group {
if let url { collected.append(url) }
}
return collected
}
// 回到MainActor上下文，统一更新状态
finished.formUnion(results)
refreshUI()
}
}这个模式的优点是清晰：子任务保持纯粹的计算与IO，不触碰共享状态；downloadAll本身标注了@MainActor，所以withTaskGroup返回后，后续代码自动回到主线程执行。即使任务组因取消而提前结束，for await循环正常退出，收尾逻辑依然安全地运行在正确的执行器上。
最后提醒两个常见陷阱：一是@Sendable闭包中捕获了非发送安全的对象（比如UIView、普通class实例），编译器会报错或要求标注隔离，务必认真对待而不是随手加nonisolated(unsafe)绕过；二是不要假设取消后Task.isCancelled检查点之间的代码不会被调度走，任何await之后执行器归属都可能变化，涉及共享状态的代码要么放在actor内部，要么显式通过@MainActor标注约束。掌握这些原则，任务取消后的清理就能稳定可靠地落在正确的执行器上。
Swift TaskGroup任务取消执行器切换修改时间：2026-09-03 23:45:01