Swift Concurrency：为所有UI访问类和结构体标记@MainActor有弊端吗？

• 安全性层面确实靠谱：把所有视图控制器（VC）和视图模型（ViewModel）标记为@MainActor，能从编译阶段就杜绝意外在非主线程操作UI的问题，不用逐个方法加标记，操作简单且能有效避免UI崩溃、渲染异常这类问题。

• 性能上的潜在弊端：

  • 所有标记@MainActor的代码默认都会调度到主线程执行，如果ViewModel里包含大量耗时操作（比如网络请求、复杂数据解析、重型计算），强行让这些任务跑在主线程会直接挤占UI渲染、用户交互的资源，导致页面掉帧、卡顿，甚至出现无响应的情况。
  • 即便是轻量逻辑，全部堆在主线程也会增加主线程的负载，在复杂页面或多任务并行场景下，这种影响会更明显。

• 架构设计上的隐患：

  • MVVM的核心是业务逻辑与UI解耦，若ViewModel全绑定主线程，相当于把业务逻辑和UI线程强关联，后续想把ViewModel复用到非UI场景（比如后台任务、Widget）时，会因为@MainActor的限制变得棘手。
  • 容易养成“所有代码都扔主线程”的惰性习惯，长期下来会让代码的并发逻辑混乱，浪费结构化并发的设计优势。

• 更合理的折中方案：

  • 仅给VC类整体标记@MainActor（VC本身和UI强关联），ViewModel则只给直接更新UI状态、触发UI操作的方法/属性标记@MainActor。
  • ViewModel中的耗时操作放在后台异步执行，完成后通过MainActor.run或者标记@MainActor的更新方法，把结果同步到主线程更新UI。
  • 用nonisolated关键字给ViewModel中不需要在主线程执行的方法解除@MainActor限制，灵活控制代码的执行线程。

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