在企业级 SAP Fiori 交付里，升级从来不是可选项：安全修复要打，浏览器版本在变，SAP BTP 的运行时也在滚动演进。真正让团队睡得安稳的，不是升级不发生，而是升级发生了也不把业务打崩。SAPUI5 把这件事说得很直白：开发控件与功能时，必须遵守一套兼容性规则，才能保证应用在更新到新版本后依旧可用。(SAPUI5 SDK)
这篇文章会以项目视角，把这套规则拆开讲透，并且结合 SAP Fiori Elements、扩展点、以及真实项目里常见的踩坑方式，给出能落地的实践清单。
为什么 SAP Fiori 生态对兼容性极度敏感
很多团队对兼容性的直觉来自前端社区：大版本可能破坏，小版本尽量不破坏，补丁包通常只修 bug。SAPUI5 的规则与这个直觉一致，但它的约束更强，因为 SAP Fiori launchpad 常常是共享运行时：多个应用在同一个壳里跑，同一套 SAPUI5 库被复用，一处不稳定的 CSS 覆盖或 DOM 操作，可能不是影响一个页面，而是影响一整套业务应用的体验一致性与可维护性。SAPUI5 也明确提醒：不要把控件内部的 HTML 结构与 CSS 类名当作稳定契约，否则升级时非常容易断。(
