iCloud 不是单一数据库：先选对服务
iCloud 包括多种不同的存储与同步能力。先按数据形态选择，再讨论具体 API。
用你的前端经验理解
可以类比偏好同步、文件同步、托管记录库和凭证同步几种产品。iCloud 备份是恢复机制，不是应用实时同步协议。
为什么需要它
iCloud 是多种能力的集合，不是一个可以随意存任意 JSON 的单一后端。少量偏好、用户文件和结构化记录的访问方式不同。对个人阅读 App，先按数据的组织和协作方式选服务：用户需要看到文档文件吗，记录需要查询吗，是否跨设备或多人共享？
它是怎样工作的
键值存储适合有限规模的轻量偏好同步，文档容器面向文件，CloudKit 面向记录与云数据库能力。SwiftData 自动同步又是在持久化层整合 CloudKit 的方案，不等于直接操作所有 CloudKit 功能。Apple 登录建立业务身份，也不会自动让你的服务器访问这个用户的私人 iCloud 数据。
把关键概念连起来
少量偏好
NSUbiquitousKeyValueStore 适合少量、低频的键值偏好，如阅读字号。配额与值类型有限，不适合文章库或大文件；仍需处理外部变化通知。
用户文档
iCloud Drive / Documents 适合文件与文档体验，涉及文件协调、下载状态和冲突版本。不能默认文件一直完整存在于本机。
结构化数据
CloudKit 适合 records、assets、关系与同步；SwiftData 可基于 CloudKit 同步兼容模型。iCloud Keychain 同步符合条件的钥匙串项，与 CloudKit 容器不是同一条链路。
同一阅读 App 中的四种数据
字号属于偏好；导出的 PDF 属于文件；文章元数据属于结构化记录；登录 token 属于凭证。它们不一定使用同一个服务，是否同步也应分别决定。
把三类数据放到合理位置
- 少量阅读偏好可以评估键值同步，但不能把数万篇正文压成一个大字符串反复覆盖。
- 用户导入并希望管理的文档按文件需求考虑文档方案；封面缓存仍应保持可重建。
- 文章元数据与阅读状态按模型关系、查询和同步复杂度选择持久化方案，再确认共享与跨平台边界。
这里需要你亲自判断
用户在 App 中“通过 Apple 登录”不会替你开启设备 iCloud，也不会让本地 SwiftData 文件自动同步。
做一个小练习
为字号偏好、Markdown 文档库、收藏记录和密码四类数据各选一个服务，并说明是否需要业务后端。
- 为偏好、PDF 文档、文章记录、refresh token 各选存储方案并写理由。
- 指出哪些数据属于用户 iCloud 身份，哪些属于自己的业务账号。
展开参考思路与验收标准
refresh token 应按敏感凭证策略保存，不混入通用云记录。服务选择应由数据语义决定；同样叫“同步”，并不代表共享相同权限、容量与冲突机制。