我仍然无法理解，NSPersistentHistoryTransaction试图解决的问题是什么，在CoreDataCloudKitDemo WWDC 2019 "使用核心数据与CloudKit">
https://github.com/software123inc/CoreDataCloudKitDemo/blob/master/CoreDataCloudKitDemo/DataProvider/CoreDataStack.swift L161
我想看看，如果不执行processPersistentHistory，会发生什么问题。
通过使processPersistentHistory为空，我尝试做以下测试:
- 在同一台机器上同时运行两个模拟器。
- 为模拟器a添加一个项目
- 由于模拟器B无法接收推送通知，我按下模拟器B的home键
- 在模拟器B中，我点击应用程序图标再次启动应用程序。
- 在模拟器B中，我可以观察到
controllerDidChangeContent被调用。我的猜测是，因为后台SQLite是由CloudKit后台任务无缝更新的，NSFetchedResultController将被通知SQLite数据库的变化，随后更新UI。查看"下载CloudKit更改为核心数据";https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit - 在模拟器B中，由于
controllerDidChangeContent被正确触发，我可以观察到NSFetchResultController执行的UI变化没有问题。
因此，我不清楚，processPersistentHistory在演示代码中试图解决什么问题。请问我可以执行什么样的测试用例，以了解processPersistentHistory解决的问题?
基于"整合与当前视图相关的商店变化">
https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit你的应用程序收到远程更改通知，当本地商店来自CloudKit的更新。但是，没有必要更新UI响应每个通知，因为有些更改可能不会与当前视图相关。
分析持久历史记录以确定更改是否存在在用户中使用它们之前与当前视图相关接口。检查每笔交易的细节，比如实体名称，其更新的属性，以及更改的类型，以决定是否采取行动。
有关持久历史跟踪的更多信息，请参见消费相关店面变更
这部分越来越令人困惑了。我们的NSFetchedResultController正在接收相关的实体更改事件，由于SQLite，随后能够更新UI正确。如果是这样，为什么我们还需要持久的历史?
你是对的，NSFetchedResultsController能够接收更新，并触发更新到UI。
所以问题变成了，在你的应用的哪个UI中你从CoreData显示数据，而不使用NSFetchedResultsController?
对于我来说，它是一个编辑项目的表单，我只是将NSFetchedResultsController中的一个项目作为表单成员变量传递给它。此表格无法接收此类更新。
看看CoreDataCloudKitDemo，还有这个DetailView，它让用户编辑一个帖子，每当这个帖子从另一个设备上删除时，具有持久的历史跟踪(和查询生成)允许它"陷阱";这将在关闭编辑表单之前显示一个弹出窗口。