當BeforeServerToken爲null時，CKFetchRecordChangesOperation似乎需要多次下載第一組數據，然後重試，直到moreComing標誌清除。CKFetchRecordChangesOperation首先返回垃圾數據
這不是因爲記錄太多 - 在我的測試中，我只有大約40個成員記錄，每個記錄都屬於6個組中的一個。
第一次傳遞給出兩個格式不正確的成員記錄;第二次傳遞有時會從尚未下載的組發送幾條成員記錄，或者什麼也不是。只有在第三次通過後，纔會按預期下載所有剩餘的組和成員。
任何想法，爲什麼這可能是？
如果區域中有很多記錄被刪除，就會發生這種情況。服務器掃描區域的所有更改，然後刪除已刪除記錄的更改。有時這可能會導致一系列零記錄更改的更改，但moreComing設置爲true。
在iOS 10/macOS 10.12中查看CKFetchRecordZoneChangesOperation上的新標記fetchAllChanges。 CloudKit將爲您提供讀取更改請求，您只會看到記錄更改和區域更改標記，直到獲取了該區域中的所有內容爲止。
這是它造成的問題，我不得不做這件事......
我有兩種類型record-組和成員（其中必須有一組爲他們的父母。）
問題是，儘管CloudKit通常首先返回記錄的父項，但它只會在一個批處理中執行此操作。
成員可能會因此其父組之前，如果是在不同批次（出現這種情況，如果一組隨後被編輯或重新命名，如，在處理順序後轉吧）
如果您收到正在設備上使用陣列來表示已下載的數據，因此您需要緩存一系列批次中的成員，並在結束時處理它們（在收到所有組之後），或允許記錄創建一個臨時虛擬組當它最終到達時會被該組名稱和其他數據覆蓋。
這是非常有趣的無證行爲。我想知道，記錄被刪除，然後再添加一個具有相同ID的記錄。因此，需要掃描的更改被更改，刪除和更改。第一個改變了，而且刪除了兩個都下降了？ – malhal
我注意到，當初始同步標記爲零時，它會顯示所有刪除的記錄標識 - 永遠都會返回。在我的情況下，就是說，我不感興趣的1200條記錄，但仍然需要處理。這是設計的嗎？ –