当BeforeServerToken为null时，CKFetchRecordChangesOperation似乎需要多次下载第一组数据，然后重试，直到moreComing标志清除。CKFetchRecordChangesOperation首先返回垃圾数据
这不是因为记录太多 - 在我的测试中，我只有大约40个成员记录，每个记录都属于6个组中的一个。
第一次传递给出两个格式不正确的成员记录;第二次传递有时会从尚未下载的组发送几条成员记录，或者什么也不是。只有在第三次通过后，才会按预期下载所有剩余的组和成员。
任何想法，为什么这可能是？
如果区域中有很多记录被删除，就会发生这种情况。服务器扫描区域的所有更改，然后删除已删除记录的更改。有时这可能会导致一系列零记录更改的更改，但moreComing设置为true。
在iOS 10/macOS 10.12中查看CKFetchRecordZoneChangesOperation上的新标记fetchAllChanges。 CloudKit将为您提供读取更改请求，您只会看到记录更改和区域更改标记，直到获取了该区域中的所有内容为止。
这是它造成的问题，我不得不做这件事......
我有两种类型record-组和成员（其中必须有一组为他们的父母。）
问题是，尽管CloudKit通常首先返回记录的父项，但它只会在一个批处理中执行此操作。
成员可能会因此其父组之前，如果是在不同批次（出现这种情况，如果一组随后被编辑或重新命名，如，在处理顺序后转吧）
如果您收到正在设备上使用阵列来表示已下载的数据，因此您需要缓存一系列批次中的成员，并在结束时处理它们（在收到所有组之后），或允许记录创建一个临时虚拟组当它最终到达时会被该组名称和其他数据覆盖。
这是非常有趣的无证行为。我想知道，记录被删除，然后再添加一个具有相同ID的记录。因此，需要扫描的更改被更改，删除和更改。第一个改变了，而且删除了两个都下降了？ – malhal
我注意到，当初始同步标记为零时，它会显示所有删除的记录标识 - 永远都会返回。在我的情况下，就是说，我不感兴趣的1200条记录，但仍然需要处理。这是设计的吗？ –