Spring Boot读取Azure CosmosDB分页后段条目数减少丢数排查

该异常和配置的3000 RU/s吞吐量无关，核心由三个问题共同导致：

• 引入的spring-data-cosmosdb:2.3.0是基于Azure Cosmos DB v2老版SDK封装的版本，存在已知的跨分区分页bug：当分页查询遍历到跨分区边界时，nextPageable()方法没有正确携带全量的续期令牌（Continuation Token），会直接跳过未扫描的分区范围，导致数据丢失。
• Cosmos DB服务端对单次查询响应有硬限制，单响应最大不超过4MB。前59页遍历的文档单条体积较小，200条总大小未触发阈值，因此可以正常返回；遍历到第60页时命中单条体积更大的文档分区，200条总大小超过4MB限制，服务端会自动截断单页返回条数到默认值25，老版本SDK没有处理该截断场景的续期逻辑，最终导致后续数据丢失。
• 代码逻辑缺陷：依赖第一页返回的getTotalElements()计算总页数，跨分区查询下该值是服务端返回的预估值，不是精确总条数，本身就存在和实际数据量不符的问题。

• 调整日志级别，将com.microsoft.azure.spring.data.cosmosdb包的日志输出级别设为DEBUG，观察第60页的请求参数：确认请求头中MaxItemCount是否被自动修改为25，同时检查下一次分页请求携带的续期令牌是否和上一页响应返回的令牌一致。
• 剥离Spring Data封装逻辑，直接用同版本原生Cosmos v2 SDK编写分页查询测试，设置相同页大小200遍历全量数据，验证是否存在相同的丢数问题，排除业务process()方法的逻辑干扰。
• 抽查容器内文档大小，确认第60页开始遍历的分区内文档单条体积是否明显大于前59页的文档，验证是否触发4MB响应大小限制。

按优先级从高到低选择：

1. 升级依赖替换有bug的老版本组件：将原有的com.microsoft.azure:spring-data-cosmosdb:2.3.0替换为v3+版本的Azure Spring Data Cosmos（groupId为com.azure，artifactId为azure-spring-data-cosmos），新版本已修复跨分区分页续期令牌丢失的问题，可自适应处理服务端的单页大小截断逻辑，不会丢数。
2. 若暂时无法升级依赖，放弃使用Spring Data的Page分页封装，直接基于原生SDK的续期令牌实现手动分页，不要依赖预计算的总页数，循环拉取直到续期令牌为空即可，参考实现如下：

   String continuationToken = null;
   int totalFetched = 0;
   do {
       FeedResponse<ItemProjection> pageResponse = cosmosContainer
               .queryItems("SELECT * FROM c", new CosmosQueryRequestOptions(), ItemProjection.class)
               .byPage(continuationToken, 200)
               .blockFirst();
       List<ItemProjection> currentPageItems = pageResponse.getResults();
       process(currentPageItems);
       totalFetched += currentPageItems.size();
       continuationToken = pageResponse.getContinuationToken();
   } while (continuationToken != null);
   

3. 临时规避方案：将分页大小从200调低到100以下，降低单页响应触发4MB大小限制的概率，但该方案无法解决老版本SDK续期令牌丢失的核心bug，仍存在数据丢失风险，不建议长期使用。

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