跨视图独立MOC更新NSFetchedResultsController方法

问题根因定位 #

• Core Data栈初始化方式错误
  你在每个视图控制器内单独写lazy var coreDataStack = CoreDataStack(modelName: "myApp")，每一次调用都会生成一套完全独立的Core Data栈，包含独立的上下文、独立的持久化存储连接。不同栈实例的上下文完全隔离，没有共享通道传递变更。这也是为什么重启应用后能看到之前保存的数据——数据只是写入了普通视图控制器独立栈的持久层，运行时两个栈的上下文根本不会互通。
• 通知监听逻辑存在严重错误
  你在普通视图控制器的通知回调里写的ConversationsViewController().fetchedResultsController，根本不是页面上正在显示的那个驱动表视图的控制器——这行代码会临时创建一个全新的ConversationsViewController实例，这个实例没有加入视图层级，也没执行过FRC的fetch操作，本质就是个空壳。你对着这个空壳的FRC调合并方法，和页面上正在运行的真实控制器没有任何关系，当然不会触发代理回调。
  同时跨视图控制器反向操作其他控制器的内部私有属性，本身就是违反封装的设计，极易因为控制器生命周期变化导致引用失效、崩溃。

正确实现步骤 #

1. 重构Core Data栈的初始化逻辑
   禁止在单个视图控制器内独立初始化Core Data栈。将栈实例改为全局单例，或在App/Scene层级统一初始化后通过依赖注入传递给所有需要使用的控制器，保证全应用所有模块使用同一套上下文实例。
2. 调整通知监听的归属
   由持有FRC的ConversationsViewController自行负责监听对应写入上下文的保存通知，在收到通知后将变更合并到自身绑定的上下文中，不要跨控制器反向操作FRC。这种实现方式和你之前参考的同类问题的解决方案逻辑完全一致，只是转换为Swift写法。
3. 注册通知时明确指定监听对象
   注册NSManagedObjectContextDidSave通知时，将object参数设置为实际执行写入操作的上下文实例，不要传nil接收全局所有保存通知，避免不必要的性能消耗和逻辑冲突。
4. 对齐执行队列
   FRC默认绑定主队列执行，合并变更的操作必须在主队列触发，才能正常触发FRC的代理回调更新UI。

参考实现代码 #

// 代码写在持有FRC的ConversationsViewController中
override func viewDidLoad() {
    super.viewDidLoad()
    // 原有FRC初始化、fetch逻辑
    do {
        try fetchedResultsController.performFetch()
    } catch {
        print("FRC fetch 失败: \(error)")
    }

    // 注册上下文保存通知，明确指定监听的写入上下文
    NotificationCenter.default.addObserver(
        self,
        selector: #selector(handleContextDidSave(_:)),
        name: .NSManagedObjectContextDidSave,
        object: sharedCoreDataStack.backgroundWriteContext
    )
}

@objc private func handleContextDidSave(_ notification: Notification) {
    // 合并操作强制在主队列执行，和FRC运行队列保持一致
    DispatchQueue.main.async { [weak self] in
        guard let self = self else { return }
        self.fetchedResultsController.managedObjectContext.mergeChanges(fromContextDidSave: notification)
    }
}

普通业务视图控制器仅需要在共享的写入上下文中完成数据创建、更新，调用上下文的save()方法即可，不需要额外编写反向调用其他控制器的逻辑。

常见注意点 #

• 不要在合并逻辑中手动调用processPendingChanges()，FRC在上下文变更时会自动处理待处理变更，手动调用反而可能导致代理方法触发时机异常。
• 确保FRC的代理方法已经正确实现了表视图的更新逻辑，跨上下文合并的变更会正常走同一套代理流程，不需要单独编写适配代码。

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