在很多 SAP Fiori 项目里，开发团队一开始把导航理解成页面 A 跳到页面 B。真正做深了才会发现，Fiori 的导航远不只是一次界面切换，它背后承载的是业务意图、应用状态恢复、跨应用协作，以及用户在浏览器中的可追溯操作路径。SAP 官方对这一点的定义非常明确：URL并不是一个单纯的地址，而是在表达一个关于导航目标的intent。也正因为如此，用户可以通过浏览器历史记录，甚至只在地址栏里输入少量字符，就回到自己高频使用的业务应用。(SAP Help Portal)很多开发者在项目初期会低估这件事的重要性。可一旦系统进入真实生产环境，问题就会接连出现：销售人员希望从订单列表一键跳到客户主数据；财务人员希望从 KPI 卡片钻取到明细分析应用；仓库主管希望从看板页返回刚才浏览过的入库详情，还要保留筛选条件和滚动位置。此时你会发现，导航如果只是靠window.location或字符串拼接硬跳，几乎一定会在维护性、可扩展性和用户体验上吃亏。Fiori 的导航机制之所以成熟，恰恰在于它把这些看似零散的需求抽象成了一套稳定的语义模型。(