这似乎是基本的核心数据问题，但我无法在Apple文档，StackOverflow或我所咨询的几本书中找到明确的答案。
这是针对iOS上的一个NSPersistentContainer。除了涉及多个NSManagedObjectContext对象之外，什么都没有。
我（想我）想要的：
UI反映了主NSManagedObjectContext（即具有mainQueueConcurrencyType的状态）的状态。对Core Data对象的更新是在后台上下文中完成的。保存后台上下文后，核心数据更改将传播到主上下文。然后，向UI通知已修改的对象，并适当地更新显示。
为什么看起来很难/笨拙/不可能：
我目前在主要上下文上使用automaticallyMergesChangesFromParent。从某种意义上说，背景更改确实可用于主要上下文，它可以正常工作。如果查询的对象尚未在内存中，则会收到更新的版本。
但是，合并来自后台上下文的更改时，主上下文中的现有对象（即，已经从后备存储中读取的对象）不会更新。我的理解是，这是核心数据的基本原则；您必须刷新对象才能查看更新。很好
问题是，NSManagedObjectContextObjectsDidChange通知是基于对活动对象的更改。主上下文可以合并来自100个不同背景上下文的更改，并且永远不会发出更新通知，因为那些通知仅针对活动对象生成-并且活动对象不会自动更新。
如果刷新主上下文中的对象（使用mainContext.refresh(obj, mergeChanges: true)），则确实会收到每个对象的更改通知。但是，更改类型始终为“刷新”，而不管对象的任何属性是否实际上已由后台上下文修改。换句话说，在将更改合并到主上下文中时，所有详细的更新信息都已丢失，并且没有从头开始进行自己的逐字段和逐关系的比较就无法恢复的方法。 。 （此过程还会使您所有的对象都变成故障，这不是最佳选择。）
我可以看到，通过手动微管理每个背景上下文并侦听其NSManagedObjectContextDidSave通知，然后将objectID手动映射回主上下文并仅刷新实际上具有对象的对象，可能有一条出路已更新。不过，我不确定确切如何在此工作流程中解决删除问题。似乎很多体力劳动。
使用多个上下文时，是否真的没有标准，可靠的方法来收集这种更新信息？