在 SAP S/4HANA 项目里，有一类问题特别容易把开发人员带偏。后台的 ABAP 代码已经激活，模型提供者已经调整，新字段明明存在，甚至相关传输请求也已经导入目标系统，可是在 SAP Fiori、SAP Gateway Client 或直接访问$metadata时，看到的模型却仍然像修改之前一样。这种场景下，继续盯着数据库表、CDS View、DPC、MPC 或 RAP Behavior Definition 检查，往往已经偏离问题中心。真正需要关注的，是 SAP Gateway Foundation 中那层平时几乎没有存在感、出现问题时却非常关键的 Metadata Cache，也就是元数据缓存。对于OData V4，这层缓存尤其需要单独理解。很多有OData V2开发经验的团队会习惯性地进入SPRO，寻找一个类似启用或停用 Metadata Cache 的开关，甚至会试图通过关闭缓存来验证问题。到了OData V4，这套思路已经行不通。SAP 当前的ABAP Platform 2025 FPS01文档仍然明确说明，SPRO中关于 Metadata Cache 启用和停用的设置只适用于OData V2，SAP Gateway Foundation 的OData V4实现没有提供关闭 Metadata Cache 的能力。这并不是 SAP 少做了一个配置项，而是OData V4Runtime 从设计上就把 Metadata
在 SAP S/4HANA 项目里，有一类问题特别容易把开发人员带偏。后台的 ABAP 代码已经激活，模型提供者已经调整，新字段明明存在，甚至相关传输请求也已经导入目标系统，可是在 SAP Fiori、SAP Gateway Client 或直接访问$metadata时，看到的模型却仍然像修改之前一样。这种场景下，继续盯着数据库表、CDS View、DPC、MPC 或 RAP Behavior Definition 检查，往往已经偏离问题中心。真正需要关注的，是 SAP Gateway Foundation 中那层平时几乎没有存在感、出现问题时却非常关键的 Metadata Cache，也就是元数据缓存。对于OData V4，这层缓存尤其需要单独理解。很多有OData V2开发经验的团队会习惯性地进入SPRO，寻找一个类似启用或停用 Metadata Cache 的开关，甚至会试图通过关闭缓存来验证问题。到了OData V4，这套思路已经行不通。SAP 当前的ABAP Platform 2025 FPS01文档仍然明确说明，SPRO中关于 Metadata Cache 启用和停用的设置只适用于OData V2，SAP Gateway Foundation 的OData V4实现没有提供关闭 Metadata Cache 的能力。这并不是 SAP 少做了一个配置项，而是OData V4Runtime 从设计上就把 Metadata
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
