一个运行中的 SAP Fiori 应用次乃至一天几十次刷新时，怎样避免把几乎没有变化的整份数据重新传输一遍。以销售订单列表为例。上午 9 点，客户端从 SAP S/4HANA 读取了 5 万条订单。上午 9 点 10 分，真正发生变化的可能只有 37 条。如果客户端再次执行同样的完整查询，SAP Gateway、ABAP 应用服务器、数据库、网络链路以及浏览器都需要重新处理 5 万条数据。业务数据越大、刷新频率越高，这类重复工作越明显。OData V4 为这种场景设计了 Change Tracking，也就是增量变化跟踪机制。在 SAP Gateway Foundation 中，与之对应的核心概念就是Prefer: odata.track-changes、@odata.deltaLink和$deltatoken。SAP 当前 ABAP Platform 2025 FPS01 文档仍然把 Delta Handling and Delta Token 列为 SAP Gateway Foundation 的 OData V4 能力。SAP 对 delta link 的描述也与 OData 规范一致，它是由服务端创建的链接，客户端通过这个链接获取从某一个时间状态开始发生的新增、修改和删除。理解这套机制时，有一个观念很重要。Delta 并不是简单地在 URL 后面加一个时间戳，也不只是数据库字段LAST_CHANGED_AT 某个时间的另一种写法。OData 把 delta link 看成服务端生成的 opaque link，也就是客户端可以保存和调用，但不应该依赖其内部结构进行解释的