在 SAP Fiori 的业务页面里，一次保存动作很少只对应一条数据库更新。销售订单可能同时修改抬头、多个行项目、合作伙伴、文本和计划行，采购场景也经常出现同一页面一次提交多组关联数据。前端如果把这些修改拆成多个独立 HTTP 请求，网络往返会增加，更麻烦的是事务边界会被切碎。某一条请求成功、另一条请求失败，业务数据就可能落在一种半完成状态里。$batch的价值不只是减少 HTTP round trip，它还给 SAP Gateway 提供了一套把多个请求组织成批次、再把相关修改组织成原子事务单元的机制。SAP 官方文档把change set明确定义成一个 Logical Unit of Work，多个修改必须整体成功或者整体失败。很多项目真正出问题的地方，并不是不会发送$batch，而是把 batch request、change set 和 ABAP LUW 混成了同一个概念。batch request 是 HTTP 层面的外壳，一个$batch请求里可以放查询操作，也可以放一个或多个 change set。change set 才是修改操作的事务边界。ABAP LUW 则是后端事务处理模型，最终数据库提交仍然落在 ABAP 运行时与数据库事务之间。把这三层关系理顺以后，CHANGESET_BEGIN和CHANGESET_END的职责就很清楚了。对于 retrieve 操作，SAP Gateway 不要求应用额外实现特殊的 change set 处理逻辑。读取请求可以作为 batch 中的独立部分被框架分派，真正需要应用层谨慎控制的是 create、upda
