Swift withCheckedContinuation如何结合Dispatch QoSClass使用

1. 带GCD调度逻辑的async/await适配写法 #

如果要严格对齐原有代码的调度逻辑，改写后的实现如下：

// 标记@MainActor保证方法返回后默认在主线程执行后续逻辑，对应旧代码回调切主队列的行为
@MainActor
static func get(
    className: String,
    objectId: String
) async -> PFObject? {
    // 高优先级任务对应旧代码DispatchQueue.global(qos: .userInteractive)的QoS配置
    return await Task.detached(priority: .high) {
        let query = PFQuery(className: className)
        // 桥接回调API到async语法，continuation本身线程安全，无需额外包队列
        return await withCheckedContinuation { continuation in
            query.getObjectInBackground(withId: objectId) { result, _ in
                continuation.resume(returning: result)
            }
        }
    }.value
}

这里的调度逻辑映射关系非常直接：

• @MainActor 是Swift并发模型里对主线程的原生抽象，替代手动调用DispatchQueue.main.async切主线程的操作，所有标记为@MainActor的方法、属性，访问时都会自动调度到主线程执行，编译器会做线程安全检查。
• Task的priority: .high 对应GCD里的.userInteractive QoS等级，保证任务调度优先级和旧逻辑一致。
• withCheckedContinuation 只负责完成回调到async语法的桥接，它本身是线程安全的，不管你在哪个线程调用resume都可以正常工作，不需要额外在回调里包队列切换。

注意：上述代码是严格对齐旧代码调度逻辑的等价实现，实际使用时完全可以删掉Task.detached这层包装——旧代码里的全局队列调度本身就是冗余操作。

2. async/await模式下手动队列调度的必要性 #

结论：你旧代码里的手动队列调度绝大多数都是冗余的，在async/await模式下完全可以删掉，不需要保留。
具体原因如下：

• 第一层DispatchQueue.global(qos: .userInteractive).async的包装从一开始就没有实际作用：Parse SDK的getObjectInBackground方法本身就会把网络请求逻辑放到内部管理的后台队列执行，不会阻塞你调用方法时所在的线程，额外套一层全局队列调度属于无意义的重复操作，不管是旧回调版本还是新版async版本都不需要加。
• 第二层手动切DispatchQueue.main的逻辑，在async/await模式下也不需要手写：只要你把需要在主线程执行的逻辑（比如调用get方法后更新UI的代码）放在MainActor上下文中，Swift并发会自动完成线程调度，编译器还会做静态检查，避免你不小心在后台线程更新UI导致的崩溃，比手动GCD切换更可靠。
• 只有当你拿到返回结果后需要执行大量CPU密集型操作（比如大批量数据解析、大尺寸图片解码等会阻塞线程的计算）时，才需要手动指定非主线程的执行上下文，普通的网络请求桥接场景完全不需要手动管理调度队列。
• 如果你的Parse SDK版本较新，SDK本身已经提供了原生async/await接口，不需要自己写withCheckedContinuation做桥接，可以直接调用，连桥接代码都可以省掉。

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