CloudKit限额疑问：共享数据库记录配额归属及生产存储异常

我来分享下我处理CloudKit配额问题的实际经验，刚好之前也踩过类似的坑，希望能帮到你。

一、用户共享数据库的配额归属 #

首先明确规则：用户共享数据库（Shared Database）中的记录，是计入发起共享的用户的个人配额，而非开发者的公共配额。

原因很简单：共享数据库是用户之间私有的数据协作空间，本质上属于用户个人数据的延伸，所以会占用该用户的CloudKit存储和传输额度；而公共数据库的配额是开发者账号下的公共资源，仅用于存储所有用户都能访问的公开数据。

二、公共数据库莫名产生数据的排查思路 #

如果你的公共范围理论上不该有数据，但请求量和存储量一直在增长，可以按以下步骤排查：

• 先查CloudKit Dashboard的公共数据库详情
  登录CloudKit Dashboard，进入公共数据库的Records、Zones、Subscriptions板块，直接查看有没有意外存在的记录。我之前就是在这里发现测试阶段遗留的测试数据——当时写Demo的时候没切换数据库实例，直接把测试内容写到公共库了。

• 检查代码中的数据库实例调用
  全局搜索代码里的publicCloudDatabase，看看是不是有逻辑错误导致写入操作指向了公共库：比如复制粘贴代码时没替换成私有库/共享库，或者条件分支判断失误（比如用户未登录时错误 fallback 到公共库写入）。

• 借助CloudKit Metrics定位请求来源
  在Dashboard的Metrics面板，筛选公共数据库的请求类型（比如CreateRecord、ModifyRecord），查看请求的时间分布、客户端版本、设备类型，能快速定位到是哪个版本的APP或者哪个操作在写入数据。

• 排查订阅与服务器端操作
  如果你用了CloudKit的服务器端服务（比如Web Services）或者设置了公共数据库的订阅，检查这些配置是不是有误：比如订阅触发了自动写入，或者服务器端脚本不小心往公共库写入了数据。

• 排除系统数据干扰
  CloudKit的一些系统级数据（比如订阅的元数据）可能会占用少量空间，但不会导致存储量持续增长，所以如果是大幅增长，基本可以排除这个可能。

内容的提问来源于stack exchange，提问作者happymilktea103