最近在做 SAP Fiori 应用技术选型时，一个很容易被忽略的问题反复出现，应用到底是因为sap.m能跑在某个浏览器上，所以整体就能跑，还是因为底层的sap.ui.core、sap.ui.layout、sap.ui.unified本身各自维护了一套独立的平台支持矩阵，所以才能支撑上层控件库运行。这个问题看起来细，实际落到项目里却很要命。因为企业级 Fiori 应用不是一个按钮、一个表格、一个页面那么简单，它背后牵涉到 UI5 Core 初始化、模块加载、数据绑定、布局计算、事件派发、主题适配、无障碍能力、浏览器能力检测，还有桌面端和移动端之间的行为差异。在 SAPUI5 的库体系里，sap.ui.core、sap.ui.layout和sap.ui.unified经常被放在一起讨论。它们不像sap.m那样直接出现在大量业务页面截图里，也不像sap.ui.table那样一眼能看出表格能力，更不像sap.viz那样带着明显的图表标签。可是它们非常像一栋大楼里的钢筋、水泥和管线，平时很少被业务用户看见，一旦哪里出了问题，整个应用体验都会受到影响。基础库不是配角，而是 SAPUI5 应用的运行底座SAPUI5是一套面向企业级 Web 应用的 UI 开发框架，它建立在HTML5、CSS3和JavaS