在 SAP Fiori 或其他 OData 消费端同时维护同一份业务数据时，有一种故障很容易被误判成普通的数据覆盖问题。某位业务人员在页面中打开一张销售订单，此时读取到的订单状态是版本 A。与此同时，另一位业务人员修改了相同订单，把它更新成版本 B。前一个页面并不知道后台数据已经发生变化，仍然拿着版本 A 的页面数据提交修改。如果服务端毫无条件地接受这次更新，版本 B 中已经保存的内容就可能被旧页面覆盖。HTTP 对这种问题早已有成熟机制，核心就是ETag和条件请求。OData 又进一步利用 HTTP ETag 实现 optimistic concurrency control，也就是乐观并发控制。SAP Gateway Foundation 并没有重新发明一套 SAP 专属并发协议，而是在 Gateway Runtime 中提供了通用的 ETag handling，让 Hub System 与 SAP Business Suite Backend System 都能够参与条件判断，并允许后台应用在必要时接管框架默认行为。SAP 官方文档明确指出，HTTP ETag 可以用于识别资源是否发生变化，也可以用于缓存校验，而 OData 会利用 ETag 完成乐观并发控制。理解 SAP Gateway 的 ETag，关键不能只盯着一个 HTTP Header。它实际连接了四个概念，资源版本、缓存校验、条件请求、并发写保护。把这四件事串起来，SAP Gateway 中很多看似零散的If-Match、If-None-Match、412 Precondition Failed、weak ETag 以及/I
