SwiftUI结合Combine实现ViewModel通信：ObservableObject与Binding方案问询

最优推荐方案：绑定写回式闭包回调 #

这是目前最适配SwiftUI声明式编程风格、同时能满足复杂详情页逻辑封装需求的实现方案，核心优势是不需要传递索引、不需要持有父ViewModel引用，同时完全保留了原生@Binding的简洁写法，代码实现如下：

// ListView代码和你最初的简单版本完全一致，不需要做任何改造
struct ListView: View {
    @StateObject var vm = ListViewModel()
    var body: some View {
        NavigationStack { // 可替换为适配版本的NavigationView
            List(Array(vm.data.enumerated()), id: \.1.id) { index, item in
                NavigationLink(destination: DetailView(item: $vm.data[index])) {
                    Text(item.name)
                }
            }
        }
    }
}

// 详情页层，持有独立的DetailViewModel，初始化时直接注入绑定的写回逻辑
struct DetailView: View {
    @StateObject private var vm: DetailViewModel
    
    init(item: Binding<Item>) {
        _vm = StateObject(wrappedValue: DetailViewModel(
            item: item.wrappedValue,
            onSave: { item.wrappedValue = $0 }
        ))
    }
    
    var body: some View {
        VStack {
            TextField("name", text: $vm.item.name)
            TextField("description", text: $vm.item.description)
            Button("save") {
                vm.save()
            }
            // 复杂状态渲染完全由DetailViewModel管理，符合分层原则
            if vm.isLoading {
                ProgressView()
            }
            if let error = vm.error {
                Text(error.localizedDescription)
                    .foregroundColor(.red)
            }
        }
    }
}

// DetailViewModel完全独立，不需要感知上层业务逻辑，可单独测试、复用
class DetailViewModel: ObservableObject {
    @Published var item: Item
    @Published var isLoading = false
    @Published var error: Error?
    private let onSave: (Item) -> Void
    
    init(item: Item, onSave: @escaping (Item) -> Void) {
        self.item = item
        self.onSave = onSave
    }
    
    func save() {
        isLoading = true
        // 可自由扩展网络请求、本地存储、FSM状态流转等复杂业务逻辑
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) { [weak self] in
            guard let self = self else { return }
            self.isLoading = false
            self.onSave(self.item)
        }
    }
}

各方案对比说明 #

• 方案1（ViewModel嵌套ViewModel）：完全不推荐，违背了ViewModel按业务域拆分的设计原则，还会额外引入内存管理、重复订阅的问题，值类型Model变成引用类型VM嵌套后，后续排序、筛选、批量更新等操作复杂度会指数级上升
• 方案2（代理模式传父VM引用）：耦合度过高，DetailViewModel依赖上层协议无法单独复用，不符合SwiftUI单向数据流的设计思想，额外传递的索引在列表动态增删时很容易出现错位失效问题
• 原始闭包回调方案：和推荐方案思路一致，但原始实现需要手动传递索引，推荐版本直接在View层利用绑定的写回能力注入回调，完全规避了索引相关的问题
• PassthroughSubject变种方案：更适合多事件场景，比如详情页除了保存还有删除、置顶等多个需要同步到列表的操作，此时可以定义枚举类型的事件通过Subject传递，比声明多个闭包更清晰易维护

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