LESSON 26 / 575 分钟
CloudKit、离线与同步
本地保存和多设备同步是不同问题。同步需要身份、延迟和冲突处理。
用你的前端经验理解
可以类比本地缓存 + 远程数据库，但苹果云服务有账户、容器和平台约束，不能当作任意后端的透明替代。
01 / 理解问题
为什么需要它
本地保存回答“这台设备是否记住”，同步回答“多台设备最终如何收敛”。网络随时可能不可用，进程也可能被终止，因此同步不是保存后顺便调用一次上传就结束。可靠应用应优先让用户完成本地工作，再独立追踪待上传、已同步或冲突状态。
它是怎样工作的
CloudKit 提供云端记录等能力，但应用仍要选定自动持久化同步或直接记录管理方案。变更到达顺序可能不同，删除必须能传播，账号退出也会改变可访问数据。不要把设备墙上时间当成绝对可靠的全局顺序；不同字段与数据类型可能需要不同冲突合并规则。
02 / 掌握要点
把关键概念连起来
1
选择
用户自己的 iCloud 数据可考虑 CloudKit；跨平台业务或复杂服务端逻辑可能仍需要自有 HTTP 后端。
2
离线
优先展示已有数据，区分正在同步、同步失败和已保存。本地成功不等于远端已同步。
3
冲突
明确两台设备同时修改、删除后再次离线更新等情况。SwiftData 的 CloudKit 集成也有模型与配置要求。
03 / 案例推演
两台设备离线修改同一篇文章
- A 修改标题，B 标记已读。若按整条记录简单覆盖，可能丢失其中一个修改；可考虑按字段合并。
- 如果两边都改标题，就需要版本检查、保留冲突副本或用户选择，不能默默假设最后本机时间最大的一方正确。
- 重新上线后验证双方最终一致，再模拟删除与离线旧副本上传，确认已删记录不会意外复活。
这里需要你亲自判断
不要承诺“瞬时无冲突同步”；真实网络和账户状态会影响完成时间。
04 / 动手验证
做一个小练习
为“手机编辑标题、电脑离线删除同一条目”写出你希望采用的冲突规则。
- 在同步实验室制造断网修改，解释本地保存与云端一致的时间差。
- 为标题、已读状态、删除分别写出冲突处理规则。
展开参考思路与验收标准
界面可以在本地保存后立即显示成功，但不应同时宣称已同步。规则必须覆盖重试和重复提交；同一个变更处理两次不应生成两份文章。
05 / 检查理解
本地保存成功说明什么？
答对理解题后即可标记完成