CloudKit：Container、Database、Record 与身份
CloudKit 是一个带身份与权限边界的记录服务。清楚理解容器和数据库类型，比先写查询更重要。
用你的前端经验理解
Container 类似应用的数据命名空间；Record 类似文档记录，但 CloudKit 不提供任意 SQL join，也不是通用业务计算服务器。
为什么需要它
CloudKit 的 Container 是应用使用的一组云资源边界，Database 再区分 public、private 和 shared 等访问场景，Record 是具体记录。理解层级后，才能排查“服务器明明有记录，设备却读不到”：你可能查询了不同容器、账号、数据库或环境，而不是代码真的丢了数据。
它是怎样工作的
私有数据库与用户 iCloud 身份关联，公共数据库不是秘密仓库，共享数据库涉及别人共享给用户的数据。Record Type 定义字段结构，Record ID 表达记录身份，记录区可用于组织某些同步范围。开发与生产环境需要明确区分，开发环境中创建的 schema 不应被假定已经可供发布版本使用。
把关键概念连起来
结构
Container 下可有数据库；Record 有 record type、record ID 和 fields，Record Zone 组织记录及变更范围，Asset 承载文件数据。用稳定 ID 标识同一条业务记录。
权限
Private database 属于当前 iCloud 用户；Public database 面向应用公共数据且仍需配置权限；Shared database 用于访问别人共享给你的记录。公开数据库不等于允许任意写入。
身份与环境
CloudKit 依赖设备 iCloud 状态，可检查 accountStatus；其用户标识与 Sign in with Apple 的 sub 不可直接等同。开发和生产环境隔离，上线前部署并验证 schema。
import CloudKit// async throws 函数内的配置/状态检查片段let container = CKContainer(identifier: "iCloud.com.example.AppleDevLab")let status = try await container.accountStatus()guard status == .available else { // 提示云端暂不可用；是否保留本地功能由产品决定 return}let database = container.privateCloudDatabase// 显式选择身份边界；尚未执行网络写入- Record 的类型名、字段与 ID 都是数据协议的一部分，应与容器 schema 保持一致。
- 构造记录不等于完成云端保存。真正读写还需选对数据库和环境，处理身份、网络与冲突结果。
用于理解当前概念的代码片段；部分示例需要放入对应工程与作用域，并补齐上下文。
同一手机上的两套身份
手机登录 iCloud 账号 A，而 App 的业务账号可能是 B。若本地数据直接接入 private CloudKit，同步边界由 A 决定；应向用户说明并定义业务账号切换策略，不能默默把 B 的资料上传到 A 的云空间。
设计私有阅读记录
- 为文章生成稳定业务标识，决定如何对应 Record ID，避免每次重试都创建新记录。
- 把标题、网址和阅读状态作为字段，明确哪些仅供本人访问；不要把敏感内容误放公共数据库。
- 在 CloudKit 工具中检查容器、环境和记录，再在第二台同账号设备读取，逐层缩小问题范围。
这里需要你亲自判断
不要拿 Apple 登录返回的 sub 直接当 CloudKit 用户 ID；不要把秘密放进 public database，也不要只在开发环境验证完就认为生产可用。
做一个小练习
给收藏夹画出容器、private database、ReadingItem record 和附件 asset，并解释更换 iCloud 账号后的隔离边界。
- 画出 container→database→record 的路径，并标出当前账号与开发/生产环境。
- 未登录 iCloud 时保留哪些本地功能，给出明确产品行为。
展开参考思路与验收标准
业务账号登录正常不代表 iCloud 可用。排查应带上资源路径与环境，不要只根据控制台“有一条记录”断定客户端查询一定正确。