关于Swift Async/Await的疑问：从旧调度队列迁移新并发模型的困惑

首先纠正你最关键的误解：await不是阻塞线程，而是挂起当前任务。

当你在主线程的异步上下文里调用await computePI()时，主线程的当前任务会被暂停，但主线程本身不会被卡死——它可以立刻去处理其他UI事件、响应用户操作。等computePI的计算完成后，系统会自动把之前挂起的任务恢复，让它从await的位置继续执行后续代码。这和直接在主线程同步执行计算完全不同，同步执行会导致UI冻结，而await的方式不会。

然后说你提到的Task包裹的问题：这不是转移问题，而是Swift并发模型的核心设计——用任务替代原来的队列调度，让代码逻辑更线性，避免嵌套闭包的回调地狱。

举个更贴合实际场景的例子，比如你要在后台计算PI，完成后更新UI：

// 假设这段代码在UI线程的异步上下文里（比如SwiftUI的.task修饰符，或者UIKit的@IBAction里用async）
Task(priority: .background) {
    // 这里的任务会被调度到后台线程池执行，不占用主线程
    let π = await computePI()
    
    // 计算完成后，切回主线程更新UI
    await MainActor.run {
        // 比如更新label的文本，刷新UI组件
        piLabel.text = "计算结果：\(π)"
    }
}

关于computePI本身的调度，如果你希望它始终在后台执行，可以给它加上nonisolated修饰，明确它不属于任何Actor（包括主线程的MainActor）：

nonisolated func computePI() async -> [Float] {
    // 长时间的CPU密集型计算
    var piDigits: [Float] = []
    // ... 计算逻辑
    return piDigits
}

这样无论谁调用它，Swift运行时都会自动把计算任务放到后台的线程池里，不会占用主线程资源。

你忽略的几个核心点：

• 任务挂起≠线程阻塞：await释放了当前线程的使用权，系统可以用这个线程处理其他任务，这是新并发模型比GCD更高效的原因之一。
• 任务调度的自动化：不需要手动指定队列，Swift运行时会根据任务类型（CPU密集/IO密集）自动分配到合适的线程池，比手动管理GCD队列更省心。
• 线性异步代码：用await替代闭包回调，代码逻辑是顺序的，可读性和可维护性比嵌套闭包强太多。
• Actor隔离：通过MainActor可以轻松切换回主线程更新UI，不需要手动写DispatchQueue.main.async。

内容的提问来源于stack exchange，提问作者zenchemical