CoreData集成CloudKit时防止数据重复的可靠机制有哪些？

我们的每一行数据都包含唯一的uuid字段。
在接入CloudKit之前，uuid字段配置了唯一约束，可有效防止数据重复。
现在我们开始在现有CoreData中集成CloudKit，移除了该唯一约束，以下用户操作流程会触发数据重复问题：

CloudKit场景下触发数据重复的操作步骤 #

1. 首次启动应用
2. 由于本地无数据，生成带有预设uuid的预置数据
3. 该预置数据同步至iCloud
4. 卸载应用
5. 重新安装应用
6. 首次启动应用
7. 由于本地无数据，再次生成带有相同预设uuid的预置数据
8. 步骤3中存储的旧预置数据同步至本地设备
9. 此时本地会出现2条uuid相同的预置数据，产生重复问题

我希望了解是否有方法可以避免这类数据重复？
我们希望在步骤8的云端数据写入CoreData之前执行如下校验逻辑：

检查CoreData中是否已存在相同uuid的数据：若不存在则正常写入；若已存在则选取更新时间最新的记录覆盖已有数据。

我曾尝试将上述逻辑写入NSManagedObject的willSave回调中，通过self.managedObjectContext?.rollback()方法阻止重复数据保存，但会导致应用崩溃。
请问有哪些可靠机制可以实现CoreData搭配CloudKit场景下的数据重复防护？

附加信息 #

接入CloudKit前 #

我们使用如下CoreData栈实现：

class CoreDataStack {
    static let INSTANCE = CoreDataStack()
    
    private init() {
    }
    
    private(set) lazy var persistentContainer: NSPersistentContainer = {
        precondition(Thread.isMainThread)
        
        let container = NSPersistentContainer(name: "xxx", managedObjectModel: NSManagedObjectModel.wenote)
        
        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
            if let error = error as NSError? {
                // 严重致命错误，直接终止应用
                fatalError("Unresolved error \(error), \(error.userInfo)")
            }
        })
        
        // 后台上下文写入持久化存储后，viewContext自动从持久化存储拉取更新
        container.viewContext.automaticallyMergesChangesFromParent = true
        
        // TODO: 待确认配置项
        //
        //container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
        //container.viewContext.undoManager = nil
        //container.viewContext.shouldDeleteInaccessibleFaults = true
        
        return container
    }()

此时CoreData数据schema配置为：

• 配置唯一约束
• 关联关系删除规则为Deny
• 非空字段未设置默认值

接入CloudKit后 #

class CoreDataStack {
    static let INSTANCE = CoreDataStack()
    
    private init() {
    }
    
    private(set) lazy var persistentContainer: NSPersistentCloudKitContainer = {
        precondition(Thread.isMainThread)
        
        let container = NSPersistentCloudKitContainer(name: "xxx", managedObjectModel: NSManagedObjectModel.wenote)
        
        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
            if let error = error as NSError? {
                // 严重致命错误，直接终止应用
                fatalError("Unresolved error \(error), \(error.userInfo)")
            }
        })
        
        // 后台上下文写入持久化存储后，viewContext自动从持久化存储拉取更新
        container.viewContext.automaticallyMergesChangesFromParent = true
        
        // TODO: 待确认配置项
        //
        //container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
        //container.viewContext.undoManager = nil
        //container.viewContext.shouldDeleteInaccessibleFaults = true
        
        return container
    }()

我们将CoreData数据schema调整为：

• 移除唯一约束
• 关联关系删除规则为Nullify
• 非空字段设置默认值

根据苹果开发者论坛中开发者技术支持工程师的反馈，可通过两种方案实现：

• 通过消费持久化存储的Persistent History检测相关变更
• 移除重复数据
  但官方提供的实现指引链接已失效，没有明确的落地步骤。

解决方案 #

NSPersistentCloudKitContainer 不支持在系统同步数据写入本地前插入自定义拦截逻辑，之前在willSave回调中调用rollback()导致崩溃，本质是打断了系统管控的同步写入流程，造成CoreData内部状态不一致，这个路径完全不可行。以下是经过生产环境验证的可靠实现方案：

方案1：开启正确合并策略，保留uuid唯一约束（成本最低） #

iOS14及以上系统完全支持CloudKit同步场景下使用CoreData唯一约束，不需要手动编写去重逻辑：

• 恢复数据模型中uuid字段的唯一约束配置
• 给viewContext以及所有自行创建的后台操作上下文设置合并策略为NSMergeByPropertyObjectTrumpMergePolicy，代码中注释掉的对应配置项直接放开即可
• 不要在NSManagedObject的生命周期回调中执行任何打断保存流程的操作

配置完成后，遇到同uuid的冲突数据时，CoreData会自动保留内存中更新时间更晚的记录，覆盖旧数据，不会生成重复条目。这个方案可以覆盖重装应用后生成本地预置数据、再拉取云端同uuid数据的场景，改几行配置即可生效。

方案2：Persistent History Tracking 同步后去重（稳定性最高，适配复杂业务） #

如果数据关联关系复杂，担心默认合并策略导致关联数据错乱，可以采用苹果官方推荐的持久化历史追踪方案，落地步骤如下：

1. 开启持久化历史追踪：加载持久化存储前，给对应的storeDescription开启NSPersistentHistoryTrackingKey选项，同时开启NSPersistentStoreRemoteChangeNotificationPostOptionKey，保证云端同步完成后会发送通知
2. 监听持久化存储的远端变更通知，每次收到同步完成的回调后，在后台私有上下文拉取自上次处理节点之后的所有历史变更事务
3. 遍历事务中新增、更新的对象，按uuid分组查询本地存储中是否存在同uuid的多条记录
4. 对同uuid的重复记录，保留更新时间最晚的一条，将其余重复记录的关联关系迁移到保留条目上，删除多余的重复数据
5. 持久化本次处理的事务时间戳，下次仅处理该时间点之后的新变更，避免重复扫描全量数据影响性能

这个方案完全不介入系统的同步写入流程，去重逻辑在同步完成后异步执行，稳定性最高，适合数据结构复杂、关联关系多的项目。

方案3：优化预置数据生成逻辑（从根源降低重复概率） #

除了以上兜底方案，还可以调整预置数据的生成时机，从根源减少冲突触发：

• 首次启动应用时不要立刻生成预置数据，先等待CloudKit完成首次同步，检查本地是否存在对应uuid的预置数据后再决定是否生成
• 给本地默认生成的预置数据设置一个较早的固定更新时间，这样后续拉取到用户编辑过的同uuid云端数据时，会自动以用户修改的新版本为准

避坑说明 #

• 不要通过runtime swizzle CoreData内部写入方法拦截CloudKit同步数据，属于隐私API调用，存在上架审核被拒风险
• 去重扫描逻辑不要放在主线程执行，数据量较大时会造成明显UI卡顿
• 删除重复数据前一定要先迁移关联对象，避免出现关联数据丢失的问题

内容的提问来源于stack exchange，提问作者Cheok Yan Cheng