对接 ERP 时按每页 100 条拉商品，第一页正常，第二页开始出现重复 SKU，最后总数还对不上。很多人只检查 currentPage，其实分页没有稳定排序时，数据库并不保证两次请求返回一致顺序。

先把最终请求URL完整记录下来

数组参数经过 SDK、网关和 URL 编码后很容易变形。确认服务端实际收到的是 searchCriteria[pageSize] 和 searchCriteria[currentPage]，页码从 1 开始。响应中的 total_count 是匹配总数，不是当前页条数。

?searchCriteria[pageSize]=100
&searchCriteria[currentPage]=2
&searchCriteria[sortOrders][0][field]=entity_id
&searchCriteria[sortOrders][0][direction]=ASC

稳定排序字段必须尽量唯一。只按 updated_at 排序时，同一秒更新的多条记录顺序可能变化；可以把 entity_id 作为第二排序，或者直接采用“上次最大 ID”方式做游标式增量。

同步期间数据在变化，offset分页天然会漂移

第一页拉完后有人新增或删除商品，第二页的 offset 已经对应另一组数据，于是产生重复或漏项。对实时变化大的订单接口尤其明显。可行做法是固定时间窗口，例如只取 updated_at 小于任务开始时间的数据，并保存最后成功同步的时间和 ID。

筛选条件也要正确分组：同一个 filter_group 内通常是 OR，不同组之间是 AND。把“更新时间大于 X”和“小于 Y”放错组，会让数据集远大于预期，表现得像分页失效。

客户端要以主键去重，但不能靠去重掩盖漏数

接收端用 entity_id 或业务唯一键做幂等写入是必要的，不过任务结束仍应核对拉取的唯一 ID 数与预期窗口 total_count。若不一致，保存每页的首尾 ID，便于重跑和定位。

最后用三种场景验证：静态数据全集、同步过程中新增一条、同步过程中更新同一秒的多条。只有在数据变化时也不漏不重，分页方案才适合生产集成。