在 SAP S/4HANA 项目里，只要一个 OData 服务开始读取销售订单、采购订单、会计凭证、物料主数据这类大规模业务集合，分页迟早都会碰到。开发环境里只有几百条测试数据时，一个普通的GET请求往往没有任何问题。到了生产系统，同一个 Entity Set 背后可能对应几十万甚至上百万条记录。如果服务一次性把整个集合全部读取出来，再序列化成 JSON，通过 HTTP 返回给 SAP Fiori、SAPUI5、移动端应用或者外围系统，数据库读取、ABAP 内存、Gateway 序列化、网络传输和前端解析都会同时承担压力。SAP Gateway Foundation 的 OData V4 因此提供了一种非常重要的机制，也就是 Server-Driven Paging，通常翻译为服务端驱动分页。$skiptoken正是这套机制里非常关键的一部分。SAP Help Portal 在当前的 SAP Gateway Foundation 文档中仍然把Response Size Reduction Via $skiptoken放在 OData V4 Additional Features 之下。其核心规则非常明确，OData 服务可以只返回集合的一部分数据。如果当前响应并没有包含请求所对应的全部结果，响应必须提供能够取得下一批数据的 Next Link。当最后一批数据已经返回完成时，响应里不能再继续提供 Next Link。这套设计看起来只是分页，但它和常见 Web 页面里的页码分页其实不是一回事。我们平时开发一个普通管理系统，经常会看到这样的接口设计。