支持用户开关CloudKit同步时如何正确清理历史跟踪事务

核心思路是不要走「关同步就全删」或者「永远不删」两个极端，用分级保留逻辑同时兼顾同步可靠性和磁盘空间控制，落地方式如下：

• 关闭同步时的基础标记
  用户手动关闭CloudKit同步的瞬间，不要执行任何历史事务删除操作，只在本地用户偏好配置里持久化两个值：
  • 关闭同步时刻的时间戳 syncDisabledAt
  • 关闭时刻已完成同步的最新历史事务ID lastSyncedTransactionId
• 日常清理规则
  把历史事务分成两类分别处理，既不会丢同步锚点，也不会让存储无限膨胀：
  • 对lastSyncedTransactionId及之前的所有历史事务：永久保留，不要清理。这部分是后续重开同步时的核心锚点依据，而且实际体积极小——CoreData历史跟踪仅存储变更元数据（实体标识、操作类型、变更字段标记），不存储完整业务数据，哪怕积累数年总占用通常也不会超过10MB，完全不存在占满磁盘的可能。
  • 对关闭同步之后新产生的历史事务：设置30天滚动保留周期，每次App冷启动、或者收到系统磁盘空间告警时，自动清理生成时间早于30天的该类事务。这部分是没有同步意义的冗余数据，也是历史事务存储占空间的主要来源，滚动清理后存储占用会稳定在固定区间，不会无限增长。
• 重开同步的兼容逻辑
  用户重新开启CloudKit同步时，先检查本地存储的lastSyncedTransactionId是否存在：
  • 若存在，直接传入该事务ID作为同步起始锚点，走系统默认增量同步流程即可，不会出现同步失败、数据冲突的问题。
  • 若该ID因为系统清理缓存、用户手动清除App数据等极端情况丢失，直接触发一次本地与云端的全量数据合并校验，使用系统默认的冲突解决策略完成首次同步即可，不会造成数据损坏。

避坑提醒：不要在关闭同步时全量删除所有历史事务，实测在iOS 15至iOS 17的所有正式版本中，只要丢失了最后一次同步对应的历史事务锚点，重开同步时CoreData会判定本地与云端存储状态不匹配，极高概率出现重复数据插入、同步进程卡死的问题，没有低成本修复方案。

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