把一段 Angular 路由守卫迁移到 SAP UI5 时，很容易产生一个直觉判断，既然 UI5 有Router、Route、beforeMatched、routeMatched，那么其中应该也存在一个类似GuardResult的返回类型，只要在路由匹配之前返回false，导航就会被取消，返回另一个路由对象，导航就会被重定向。这个判断只对了一半。SAP UI5 确实能够实现登录检查、权限检查、未保存数据确认、条件跳转和异步校验，但标准sap.ui.core.routing.Router并没有提供一个与 AngularGuardResult对等的公共类型，也没有让路由事件处理函数通过返回值控制导航结果的协议。结论可以直接落在一句话上，SAP UI5 没有内置的GuardResult，beforeMatched也不是 Angular 路由守卫。若我们的 UI5 项目需要同等级别的导航控制，应当在Router之上建立一层可等待、可拒绝、可重定向的导航服务，而不是依赖beforeMatched的返回值。理解这个结论，需要先把 Angular 的GuardResult拆开看。Angular 官方定义非常简洁。
把一段 Angular 路由守卫迁移到 SAP UI5 时，很容易产生一个直觉判断，既然 UI5 有Router、Route、beforeMatched、routeMatched，那么其中应该也存在一个类似GuardResult的返回类型，只要在路由匹配之前返回false，导航就会被取消，返回另一个路由对象，导航就会被重定向。这个判断只对了一半。SAP UI5 确实能够实现登录检查、权限检查、未保存数据确认、条件跳转和异步校验，但标准sap.ui.core.routing.Router并没有提供一个与 AngularGuardResult对等的公共类型，也没有让路由事件处理函数通过返回值控制导航结果的协议。结论可以直接落在一句话上，SAP UI5 没有内置的GuardResult，beforeMatched也不是 Angular 路由守卫。若我们的 UI5 项目需要同等级别的导航控制，应当在Router之上建立一层可等待、可拒绝、可重定向的导航服务，而不是依赖beforeMatched的返回值。理解这个结论，需要先把 Angular 的GuardResult拆开看。Angular 官方定义非常简洁。
