凌晨的接口批处理刚跑完，第二天一早业务系统又新增了几百条订单、修改了一批交货状态，还删除了若干已经作废的数据。如果消费端为了拿到这些变化，每隔几分钟都重新读取几十万甚至几百万条完整数据，网络、Gateway、ABAP 应用服务器和数据库都会为大量重复数据付出成本。Delta Query 解决的正是这种问题。客户端先得到一个能够代表某个同步位置的 Delta Token，后续请求不再问服务端把全部数据再给一遍，而是告诉服务端从上次同步位置开始，把新增、修改和删除的变化交出来。SAP 官方对 Delta Query 的定位就是一种面向变化数据的拉取机制，Catalog Service 也是文档明确提到的应用场景之一。这个机制看上去只有一个 token，真正进入 SAP Gateway 项目以后，难点却几乎都落在 token 背后的语义上。它到底代表数据库提交时间、业务对象更新时间、变更日志序号，还是某个一致性快照的位置。它应该在什么时候生成。删除的数据已经从主表消失以后又从哪里找回来。多个时区怎么比较。分页过程中数据继续变化会不会漏数。客户端拿着几个月前的 token 回来时服务端还是否有能力恢复那段历史。把这些问题想清楚，Delta Query 才是一套可靠的数据同步协议，而不只是给 URL 多塞一个$deltatoken参数。Delta Token 不是一个时间字符串，而是一份同步契约SAP Gateway 的实现要求很明确，支持 Delta Query 的服务需要在普通 Feed 响应中发出 Delta Token，让消费端知道后续可以基于该 token 请求增量。token 的构造方式由服务提供方决定，常见做法是日期时间值。