SwiftData + CloudKit：从本地保存到自动同步
这条路径能减少同步基础设施代码，但工程配置、兼容模型和真实同步状态仍需要你负责。
用你的前端经验理解
类似本地 ORM 加云端镜像，不是让普通 SQLite 文件直接在两台设备间复制，更不是写入后所有设备立刻一致。
为什么需要它
SwiftData 的云同步可以减少自行编写记录上传与合并的工作，但不是开启一个开关后所有模型都自动兼容。模型约束、关系、CloudKit 容器和能力配置要满足整合要求。先让本地持久化正确，再添加同步，能区分模型错误与云端配置错误。
它是怎样工作的
系统负责把本地持久化变更与 CloudKit 协调，完成本地 save 不代表另一设备立即收到。模型需要按当前官方同步要求设计，例如字段默认值或可选性、关系以及不兼容的约束；不能把仅本地可用的唯一约束直接当成云端全局唯一保证。已有用户数据还需要迁移，不能直接重建存储解决。
把关键概念连起来
工程配置
给相关 App Target 配置 iCloud/CloudKit 容器，按官方指南启用必要的 Background Modes / Remote notifications 与签名权限，并将 ModelConfiguration 连接到正确容器。
模型兼容
按当前 SwiftData 云同步指南检查属性默认值/可选性、关系、删除规则和不受支持的约束。不要把纯本地模型支持的所有能力默认用于云同步；演进 schema 前先考虑迁移。
验证路径
两台设备使用预期 iCloud 账号，先验证本地保存，再验证另一端拉取、离线重连、冷启动和生产 schema。框架负责大量调度，但不承诺固定同步时延。
最小同步验收
手机新增一篇文章，重启后仍存在，这是本地验收；Mac 随后收到相同条目，是跨设备验收。接着在 Mac 离线编辑，恢复网络后确认两端收敛，并检查没有重复记录。
把本地阅读清单升级为跨设备
- 在开发环境配置合适容器与能力，审查模型是否符合云同步要求，并记录最低系统条件。
- 在 A 设备新增记录并确认本地可重启恢复，再在 B 设备等待同步，分开观察本地与远端结果。
- 测试断网修改、恢复网络和账号变化；发布前确认生产 schema 与当前模型一致。
这里需要你亲自判断
ModelContext.save() 成功只说明本地保存完成，不证明另一台设备已收到；没有可观测证据时不要显示“所有设备已同步”。
做一个小练习
在现有收藏夹中加入 CloudKit 配置，先用两台测试设备验证添加与删除，再断网修改后恢复网络。
- 用两台设备分别验证新增、修改、删除，并记录它们最终收敛而非立即同步。
- 准备旧版本本地数据，验证启用同步后的迁移与重复记录处理。
展开参考思路与验收标准
自动同步降低实现量，却不会取消离线、延迟和模型演进的产品问题。需要精确控制自定义冲突、复杂共享或非苹果客户端时，应重新评估架构边界。