Swift 并发编程深度Q&A：直面数据竞争安全与迁移挑战

一、最常见的误解：将代码现代化与启用完整并发检查混为一谈

Holly 指出，许多开发者期望一步到位，同时完成「使用 async/await 等现代特性」和「开启 Swift 6 严格并发检查」，这往往导致大量诊断信息令人无所适从。实际上，这是两个可独立推进的步骤：

1. 代码现代化：将回调地狱改为 async/await，引入 Actor 和 Task，但可暂时保留部分旧有同步机制。
2. 启用数据竞争安全诊断：通过 Xcode 的 Upcoming Features 或全量开启 Swift 6 模式，修复编译器提示的潜在数据竞争。

两者顺序无需固定，关键在于迭代。Jeremy 分享 Foundation 的迁移经验时提到，团队先开启诊断，再逐步为类型添加 Sendable 标注或 @MainActor，许多警告会成片消失。Seema 则建议先开启 Swift 5 下的严格并发检查（Strict Concurrency Checking），以预览问题全貌，再用 @nonisolated(unsafe) 等临时 escape hatch 渐进式推进。

二、Task 与 @MainActor：如何写出正确且流畅的并发代码

三、厘清隔离域：Actor、nonisolated 与 @concurrent 的正确使用场景

Swift 通过隔离域（isolation domain）将可变状态保护起来。Alan 解释，nonisolated 表示声明不偏好任何特定隔离域，可自由地在任何上下文中调用。而 @concurrent 则是显式要求异步函数必须派发到全局共享线程池，它替代了早期 async 函数隐式跳到后台的行为（即 nonisolated async 在 Upcoming Features 启用后的新语义）。

关于何时使用 Actor，工程师一致强调：尽量少用 Actor。每个 Actor 都是一个独立隔离域，跨域访问必须 await，这会增加程序复杂度。只有当某个类型确实拥有需要被串行访问的可变状态（如网络缓存、数据库连接）时，才值得引入 Actor。大多数同步代码应保持同步，除非有明确的并发需求。

四、SwiftUI 中的并发实践：从任务启动到数据同步

• .task 修饰符的取消时机：当视图从 UI 中移除（如被 if 分支销毁）时，其关联的任务会被自动取消；但简单状态变更导致的视图重绘不会触发取消，因为视图实例并未销毁。
• 如何从 Actor 向 SwiftUI 暴露数据：跨隔离域必然需要同步层。一种常见做法是创建在主 Actor 上运行的 observable 代理，负责 await Actor 数据并在更新时触发 UI 刷新。尽管会引入一些样板代码，但这是保证数据一致性的必要代价。若遇到困难，可向 Apple 提交反馈并附上示例项目。
• 按钮点击发起网络请求：建议将异步逻辑下沉到模型层，视图只负责触发同步操作（如调用模型的方法），模型内部再启动 Task 并自行管理取消。这有利于单元测试和职责分离。

五、从 GCD/OperationQueue 迁移：厚积薄发，而非推到重来

Jeremy 详细介绍了 Foundation 框架的迁移哲学：增量式、靶向优先。先找出容易标注（如给纯值类型添加 Sendable，将 UI 相关类标记 @MainActor）的代码，通过开启 Upcoming Features 逐类诊断验证，再逐步解决更复杂的部分（如重新设计 NotificationCenter 的异步 API）。

Holly 补充，对于旧的不常修改的代码，不必强行重写；优先确保新代码以符合并发模型的方式编写，旧代码可随时间在有实际需求时再触碰。使用 @preconcurrency 或 @nonisolated(unsafe) 可以暂时桥接新旧两种模式。

针对大量文件并行处理场景，不要理论化方案，先使用最直接的创建多个 Task 的方式，通过 Instruments 分析后再决定是否引入批处理或任务组（TaskGroup）。

六、值得关注的新特性与社区参与

回答中透露了多个即将在 Swift 6.4 中实装的提案：

• 任务错误忽略警告：未处理错误的 Task 将产生编译诊断，强制开发者显式处理。
• 异步代码在 defer 块中直接执行：无需额外语法，简化清理逻辑。
• 带超时的任务执行（提案名称暂为 withDeadline）：超过时限自动取消。

Seema 建议通过 Swift 导师计划（Mentorship Program）开始为开源项目做贡献，除提交代码外，对并发诊断提出疑问或参与论坛讨论也是极具价值的贡献方式。Holly 强调，许多编译器诊断改善正是源于社区的反馈细节。