在 SAP Gateway 项目里，单独实现ETag往往并不困难，单独实现$batch也不算少见。真正容易踩坑的是两者叠加，也就是一个 OData 客户端通过$batch一次提交多条修改请求，而这些修改请求又依赖ETag做乐观并发控制。这种组合在 SAP Fiori、SAPUI5、移动应用以及外围系统批量更新 S/4HANA 业务对象时很常见。表面上看，只是把几个PATCH、MERGE、PUT或DELETE塞进同一个$batch。到了 Gateway Runtime 内部，问题却已经从单条 HTTP 请求的并发检查，升级成了一个 changeset 内多条业务操作的事务一致性问题。SAP Gateway 对 changeset 有非常明确的事务语义。一个 changeset 被当作一个Logical Unit of Work，也就是一个LUW，需要保持all or nothing的特征。某一个 operation 失败时，整个 changeset 不能留下半成功半失败的业务状态。而ETag恰好处理的是另一种一致性问题，也就是并发修改。假定销售订单5000000123在数据库里的当前版本对应ETag A。SAP Fiori 在上午读取这张销售订单时拿到了ETa
