一个 SAP Fiori 销售订单对象页，页面上同时要显示订单抬头、客户信息、订单行项目、金额汇总和状态。业务数据其实并不复杂，数据库里的记录数也不算多，ST05 里甚至看不到特别夸张的慢 SQL，可页面从点击到完全可用仍然要等上几秒。遇到这类问题，团队很容易把注意力全部集中到 ABAPSELECT、CDS View、HANA 执行计划或者某个 BAPI 上，却忽略了另一个经常更加隐蔽的性能成本，客户端为了完成一次业务操作，到底向 SAP Gateway 发出了多少次 HTTP 请求，SAP Gateway 又为了这些请求访问了多少次后端业务逻辑。SAP Gateway 的 OData 性能优化，有一个非常实用的判断视角，我们不只计算单条请求执行了多少毫秒，还要计算完成一次用户操作到底发生了多少次网络往返、多少次 Gateway Runtime 调度、多少次后端调用、多少次数据库访问，以及最终传输了多少并没有真正展示在页面上的数据。SAP 官方的性能最佳实践对此给出了相当明确的建议，一次业务操作不应该从客户端到 SAP Gateway 产生超过两次往返。如果已经需要三个、四个甚至更多彼此独立的请求，就应该重新审视请求模型，而不是继续增加并行 AJAX 调用。对于超过两个并行请求的情况，SAP 推荐考虑$batch，因为过多并行调用会同时消耗服务器资源与网络带宽。这条规则看起来简单，真正落实到 SAP Fiori 和 OData 项目里却很容易被破坏。以销售订单页面为例，假设客户端读取订单抬头调用一次SalesOrderSet，读取行项目再调用一次SalesOrderItemSet，为了拿