引子：一个被过度神化的架构“银弹”
MVVM（Model-View-ViewModel）在iOS开发中几乎成了默认的架构标准。无数团队在UIKit时代凭借它成功应对了复杂业务逻辑与视图的分离。然而，当SwiftUI于2019年问世，其核心设计哲学是“数据驱动视图”，且视图本身是轻量的值类型，而MVVM的ViewModel却强行将引用语义（class）塞进这个值语义的世界。这种不匹配所带来的后果是：状态被过度封装，视图刷新粒度极其粗糙，性能问题频发。我们是否问过自己：真的是SwiftUI不够好，还是我们在用旧的思维扼杀了它的天赋？
更令人遗憾的是，很多开发者在迁移到SwiftUI后，依然从UIKit时代照搬@ObservedObject和@StateObject。他们认为ViewModel是必要的“中间层”，却忽略了SwiftUI的View本身就是一个完美的“Reducer”——它已经包含了状态和动作的绑定。当我们使用引用类型作为状态容器时，SwiftUI的依赖追踪系统会因为无法精确判断哪个视图实际依赖哪个属性，而被迫触发整棵视图树的重算。这不仅浪费CPU，更让动画和交互变得卡顿。这个问题的根源，恰恰就是MVVM的“凡尔赛式”封装。
解剖：为什么MVVM在SwiftUI中成为“反模式”
首先，@StateObject的生命周期由View的构造和销毁决定，这意味着一个拥有复杂业务逻辑的ViewModel会在视图消失时被销毁，其内部状态无法被真正持久化。为了修复这一点，开发者不得不引入外部存储或手动管理注入，这反而让架构变得更加臃肿。其次，一个ViewModel通常会聚合多个@Published属性，哪怕只是一个简单的列表页面，也可能暴露isLoading、items、error等多个可观察源。这些属性中任何一个发生变更，SwiftUI都会通知所有对该ObservableObject发起依赖的视图，即便某个视图只关心items，也会因为isLoading的翻转而重新求值。
这种“状态信噪比”极低的渲染机制，是MVVM在SwiftUI环境下最致命的性能缺口。我们常看到有人用Instruments Profile发现大量的body调用，却不知罪的源头正是ViewModel的粗粒度发布。更隐蔽的是，MVVM鼓励在ViewModel中直接修改状态，导致同一份数据的多个副本散落在不同类实例中，一旦某处忘了同步，就会出现用户看到的数据与模型不一致的“幽灵状态”。这些痛点，SwiftUI的原始设计其实早已给出了解药——只是被我们无视了。
破局：用“原子化状态”与单向数据流重构SwiftUI心智模型
Swift 5.9引入的@Observable宏，在保留值语义的前提下，提供了细粒度的属性观察能力。这意味着我们可以将自己的领域模型直接设计为struct，并使用@State持有它们，再通过@Bindable或直接传递Binding来驱动视图。这个模式天然地与单向数据流契合：状态作为不可变的快照存储在唯一的Store中，View通过Binding将用户操作发送为Intent，Store内的Reducer负责产生新的状态。整个过程是纯函数式的、可预测的，且因为State是值类型，你永远不会看到“引用泄漏”导致的意外共享。
下面我给出一个基于该范式的TodoList实现片段。注意，我们不再需要任何ObservableObject，而是用一个@Observable的AppStore类（或strict）作为唯一入口，其中通过@ObservationIgnored隔离非UI依赖。实际上，更好的做法是让Store本身也变成struct，配合actor处理异步逻辑。但为了简洁，我们这里用@Observable宏来演示：
@Observable
final class TodoStore {
var items: [TodoItem] = []
var filter: Filter = .all
func add(_ item: TodoItem) {
items.append(item)
}
func toggle(_ item: TodoItem) {
guard let idx = items.firstIndex(where: { $0.id == item.id }) else { return }
items[idx].isDone.toggle()
}
}
struct TodoListView: View {
@State private var store = TodoStore()
var body: some View {
List(store.items.filter { store.filter.accepts($0) }) { item in
Button(item.title) {
store.toggle(item)
}
}
}
}
注意，这里store是@State，它是引用类型（class）的前提下，SwiftUI会将其视为“Observable引用”。实际上，在使用@Observable宏时，@State已经足够追踪其内部任何属性的变化，并只刷新依赖该属性的视图。这已经被Apple在WWDC23中验证过。我们需要做的，是进一步内化“状态只来源于Store，动作只通过方法”这一单向约束。
并行？不，是并发：让Swift Concurrency为状态流转护航
当你的应用中出现了网络请求、数据库读写或一切耗时操作时，我们更应避免在View中直接使用Task并分散修改状态。相反，我们应该将这些副作用封装为Suspend函数，并通过Store中定义的异步Action来触发。例如，当用户下拉刷新时，我们调用await store.refresh()。在这个方法内部，Swift Concurrency的actor可以保证状态修改的串行性，避免数据竞争。同时，我们可以利用AsyncStream或Debounce来控制请求频率，配合@Observable的粒度提醒，实现仅对加载状态相关的视图进行局部刷新，而其他视图完全不受干扰。
这种模式的另一大优势是测试性。由于Reducer是纯函数，我们可以将状态变化分解为(State, Action) -> State的映射，然后直接针对这个函数做单元测试，无需UI自动化。Swift Concurrency的Task和AsyncStream也让并发流程变得可预测，从而在架构层面消灭了一整类由状态同步引起的诡异Bug。
最后的呐喊：回归SwiftUI的本原之美
SwiftUI并不是一个“需要被MVVM拯救”的UI框架，恰恰相反，它的声明式语法和值语义已经内置了更现代的状态管理理念。当我们抓住@Observable、@State和Binding的精髓，并采用单向数据流来组织业务逻辑时，会发现整个应用变得透明而优雅。视图只是状态的函数，状态只由Action驱动，Action永远来自用户的意图。这一刻，MVVM不再是必需品，而只是历史包袱。
希望所有iOS开发者都能勇敢地放下那些从UIKit时代继承的“老而弥坚”的架构执念，去亲身体验SwiftUI原生的状态管理哲学。你会发现，当你在代码中移除最后一个ObservableObject的瞬间，那种额外的轻盈感，正是SwiftUI为你准备已久的礼物。让我们用更少的管理，换取更多的思考；用更清晰的数据流，雕刻更持久的应用。