一套 SAP Gateway OData 服务运行得足够久以后，迟早会碰到一个很现实的问题，数据量已经大到一次 HTTP 请求不适合全部返回。于是服务端开始分页，第一页返回一批数据，同时给出next link，客户端沿着这个链接继续读取第二页、第三页，直到完整结果集被取完。单看分页，这件事并不复杂。麻烦出现在分页和增量同步同时存在的时候。假设客户端在 14:00:00 发出查询，SAP 后端此时存在 10 万条符合条件的数据。服务端每页只返回 1000 条，因此整个结果集需要大约 100 次请求才能读取完毕。如果读取过程中业务系统仍然在线运行，那么销售订单、采购订单、库存、用户消息或者通知记录都可能继续发生变化。到了 14:03:00，客户端终于读完最后一页。如果delta token到这个时候才生成，那么 14:00 到 14:03 之间发生的变化就已经处于一个非常尴尬的位置。它们有些可能出现在分页结果里，有些可能没有出现，而下一次增量查询又可能认为这些变化已经包含在上一轮同步中。这正是服务端分页与Delta Query组合时最需要解决的数据一致性问题。在 SAP Gateway 的设计里，更可靠的做法是，在原始查询真正执行的那个时间点就确定delta token。后面无论整个分页过程持续多久，这个 token 所代表的增量基线都保持不变。分页使用的next link不仅携带$skiptoken，还继续携带最初计算出的deltatoken。这样等整套分页读取完成以后，客户端可以拿