在Swift并发编程中，取消（Cancellation）是最容易被误解的机制之一。很多开发者以为调用task.cancel()之后任务就会立即停止执行，实际上Swift采用的是协作式取消模型：取消只是一个"请求"，任务是否真正停止，取决于任务内部的代码是否主动检查取消状态并做出响应。如果你在循环中处理大量数据、执行长时间下载或者做密集计算时从不检查取消状态，那么即使外部已经调用了cancel，任务依然会跑完全程，白白消耗CPU和网络资源。本文将围绕Task.isCancelled检查与协作式取消展开，帮助你写出真正可响应取消的长时间运行任务。
协作式取消的底层原理
Swift并发模型在设计上选择了协作式取消而非抢占式取消，这个决定有其深刻的技术考量。抢占式取消意味着运行时可以在任意指令处强行终止任务，这听起来很方便，但会带来严重后果：资源无法释放、锁无法解开、文件可能处于半写入状态、数据库事务可能中途断开导致数据不一致。协作式取消则把控制权交给任务本身，运行时只负责标记取消状态，由任务在安全的时间点自行决定如何退出。
具体来说，当你调用task.cancel()时，Swift运行时会做两件事：第一，将该任务的取消标志置为true；第二，如果任务正在某个挂起点等待（比如await一个网络请求），运行时会尝试中断这个等待并抛出CancellationError。注意第二点的前提是"正在挂起点等待"，如果任务正在执行纯同步的计算代码，比如一个巨大的for循环，运行时是没有任何机会介入的，此时唯一的退出方式就是代码自己检查取消状态。
这个设计可以类比为餐厅点餐：抢占式取消相当于顾客直接把厨房的火关了，锅里的菜可能夹生；协作式取消相当于顾客喊一声"不要了"，厨师在合适的步骤停下来，把灶台收拾干净。理解了这一点，你就能明白为什么取消检查必须由开发者显式编写。
Task.isCancelled与checkCancellation的用法对比
Swift提供了两种主要的取消检查方式。第一种是检查Task.isCancelled属性，它返回一个布尔值表示当前任务是否已被取消，适合那些需要执行清理逻辑再退出的场景。第二种是调用try Task.checkCancellation()，它是一个静态方法，如果任务已被取消就直接抛出CancellationError，适合在能抛错的异步函数中使用，代码更简洁。
两者的核心区别在于控制粒度。使用isCancelled时你可以自定义退出方式，比如返回部分结果、回滚事务、记录日志；而checkCancellation则直接抛错，把处理交给上层调用者。下面这个例子演示了两种方式的典型写法：
// 方式一：检查 isCancelled，手动退出
func processItems(_ items: [Int]) async -> [Int] {
var results: [Int] = []
for item in items {
// 每处理一批就检查一次取消状态
if Task.isCancelled {
print("任务被取消，已处理 \(results.count) 项")
return results // 返回已完成的部分结果
}
results.append(item * 2)
}
return results
}
// 方式二：使用 checkCancellation，直接抛错
func fetchAllPages() async throws -> [String] {
var pages: [String] = []
for page in 1...100 {
// 已取消则抛出 CancellationError
try Task.checkCancellation()
let data = try await fetchPage(page)
pages.append(data)
}
return pages
}还有一个容易被忽视的知识点：Task.isCancelled和Task.current一样，是通过任务局部上下文获取的，它检查的是"当前正在执行的代码所处的任务"。也就是说，你不能在一个任务里检查另一个任务是否被取消。如果你需要检查外部持有的任务句柄，应该使用task.isCancelled（实例属性）而不是Task.isCancelled（静态属性），两者拼写几乎一样但含义完全不同，这是实际开发中非常常见的混淆点。
长时间运行任务的取消检查点设计
对于长时间运行的任务，取消检查点的布置位置直接决定了响应速度。基本原则是：检查频率越高，取消响应越及时，但检查本身也有微小开销，需要在性能和响应性之间取得平衡。实践中通常在以下位置设置检查点：循环的每次迭代或每N次迭代、每个await调用之后、每个批处理单元开始前、以及任何耗时超过几十毫秒的同步计算块之间。
以一个图片批量处理任务为例，假设要处理上千张图片，每张处理耗时几百毫秒，如果只在循环外检查一次取消，用户点击取消按钮后可能要等好几秒才有反应。合理的做法是每张图片处理前都检查：
func processImages(_ urls: [URL]) async throws -> [UIImage] {
var processed: [UIImage] = []
for (index, url) in urls.enumerated() {
// 每张图片处理前检查取消状态
guard !Task.isCancelled else {
throw CancellationError()
}
let image = try await loadImage(url)
let processedImage = try await enhance(image)
processed.append(processedImage)
// 进度回调也可以在这里触发
await MainActor.run {
progressHandler?(Double(index + 1) / Double(urls.count))
}
}
return processed
}对于纯CPU密集型的同步计算，比如音视频转码或大数据排序，情况更棘手。因为同步代码块内无法被中断，你需要在计算内部人为插入检查点，甚至把大任务拆分成小块，用Task.yield()让出执行权。下面是一个在密集计算循环中插入让出点的示例：
func heavyComputation(data: [Double]) async throws -> Double {
var total: Double = 0
for (i, value) in data.enumerated() {
// 每处理一万条让出一次，给运行时响应取消的机会
if i % 10_000 == 0 {
await Task.yield()
try Task.checkCancellation()
}
total += sqrt(value)
}
return total
}值得注意的是，Task.yield()的作用是让当前任务暂时让出线程，给其他任务执行机会，同时也给了运行时传递取消信号的时间窗口。这种技巧在处理超大循环时特别有用，能让长任务既不阻塞线程，又能及时响应取消。
结构化并发中的取消自动传播
结构化并发是Swift并发模型的一大亮点，它带来了取消的自动传播机制。当父任务被取消时，其作用域内通过async let或withTaskGroup创建的所有子任务都会被自动取消，无需手动传递取消信号。这意味着在结构良好的代码中，你往往不需要在最外层逐层调用cancel，取消会像涟漪一样从父任务扩散到所有子任务。
func loadDashboard() async throws -> Dashboard {
// 三个并行请求，任一失败或父任务取消时全部自动取消
async let profile = fetchProfile()
async let orders = fetchOrders()
async let notifications = fetchNotifications()
return try await Dashboard(
profile: profile,
orders: orders,
notifications: notifications
)
}上面这个例子中，如果loadDashboard所在的任务被取消，三个子请求会全部收到取消信号。不过要注意，自动传播的前提是子任务运行在结构化作用域内。如果你用Task {}（非结构化任务）或Task.detached {}（分离任务）启动了后台工作，这些任务与父级没有结构关系，取消不会自动传播，必须自己持有任务句柄并手动管理。常见的错误就是在SwiftUI视图的task修饰符内部又用Task {}启动了一个下载任务，结果视图销毁时取消的只是外层结构化任务，内层的非结构化下载任务继续运行，造成流量浪费甚至内存泄漏。
在SwiftUI中，视图的.task修饰符会在视图消失时自动取消其关联任务，这是一个非常实用的特性。如果你希望用户离开页面后停止后台加载，正确做法是把工作直接放在.task闭包里，或者使用.task(id:)绑定到会变化的数据，让系统在数据变化时自动取消并重启任务，而不是手动管理任务句柄。
取消处理的常见陷阱与最佳实践
第一个陷阱是吞掉CancellationError。有些开发者喜欢在catch分支里把所有错误都处理掉，包括取消错误，这会导致调用方误以为任务正常完成，返回了一个不完整的结果。规范做法是在catch中单独识别取消错误并重新抛出或者按取消语义处理：
func safeFetch() async throws -> Data {
do {
return try await fetchData()
} catch is CancellationError {
// 取消不是错误，向上传递取消语义
throw CancellationError()
} catch {
// 其他错误可以转换为业务错误
throw APIError.networkFailure(underlying: error)
}
}第二个陷阱是取消后的清理工作。取消退出时可能需要关闭文件句柄、回滚数据库事务或取消系统提供的异步操作。对于后者，Swift提供了专门的API：withTaskCancellationHandler允许你注册一个取消回调，在任务被取消时执行特定操作，比如取消底层的URLSession任务：
func downloadWithHandler(from url: URL) async throws -> Data {
let (data, task) = try await withTaskCancellationHandler {
// 任务主体
let (data, _) = try await URLSession.shared.data(from: url)
return data
} onCancel: {
// 任务被取消时同步触发，可在这里中断底层操作
print("下载已请求取消")
}
return data
}第三个陷阱是过度检查带来的性能损耗。虽然isCancelled检查本身非常轻量，但在每条数据处理都检查的极端场景下仍有开销，合理的策略是根据单次迭代耗时决定检查频率：迭代耗时超过一毫秒就每轮检查，否则每N轮检查一次。总结起来，编写可取消任务的心法是：识别任务中的每个"安全停下点"，在这些点上检查取消，设计好取消后的清理路径，并尽量使用结构化并发让取消自动传播。掌握了这套思路，你写出的异步代码才能真正对用户操作和网络变化做出敏捷响应。
Swift取消机制Task.isCancelledasync await修改时间：2026-09-09 19:59:03