从 SAPUI5 升级不翻车说起，Compatibility Rules 在 Fiori 项目里的真实价值

最近做 SAP Fiori 项目，最容易被低估的一件事，不是某个 List Report 页面怎么加按钮，也不是 Object Page 上某个 section 怎么调顺序，而是 SAPUI5 升级之后，旧应用还能不能稳定运行。

很多团队对 SAPUI5 的理解停留在控件库层面，觉得sap.m.Button、sap.m.Table、sap.ui.layout.form.SimpleForm这些控件只要能渲染出来，项目就算过关。可是到了真实的企业环境，事情不会这么简单。我们的 Fiori 应用通常跑在 SAP Fiori launchpad 里，SAPUI5 版本可能由平台统一提供。今天代码在开发机上用某个版本正常运行，过几个月后平台 patch 升级，或者 S/4HANA 升级带来新的 SAPUI5 版本，原本看起来很稳的页面突然出现样式错位、事件失效、私有方法找不到、表格行为变化，这种问题排查起来非常折磨。

Compatibility Rules 讲的就是这个边界。它不是一份单纯写给框架开发者看的规则，也不是一份只在理论上成立的升级说明。它更像是 SAPUI5 和应用开发者之间的一份长期契约，告诉我们哪些东西可以放心依赖，哪些东西看起来可用，但将来随时可能变化。对于 SAP Fiori Elements、freestyle SAPUI5、自定义 control、自定义 reuse library 来说，这份契约直接决定代码是否具备可升级性。

public API 才是稳定契约，Demo Kit 里没写的就不要当成承诺

在 SAPUI5 里谈 API，