然后遍历本地完整路由，在循环中将路径拼接成上述结构中的key格式，通过hashMenus[route]就可以判断路由是否匹配，具体实现见App.vue文件中的getRoutes()方法。
如果后端返回的路由权限数据与约定不同，就需要自行实现筛选逻辑，只要能得到实际可用的路由数据就可以，最终使用addRoutes()方法将他们动态添加到路由实例中，注意404页面的模糊匹配一定要放在最后。
动态菜单
路由数据可以直接用来生成导航菜单，但路由数据是在根组件中得到的，导航菜单存在于index.vue组件中，显然我们需要通过某种方式共享菜单数据，方法有很多，一般来说首先想到的是Vuex，但菜单数据在整个用户会话过程中不会发生改变，这并不是Vuex的最佳使用场景，而且为了尽量减少不必要的依赖，这里用了最简单直接的方法，把菜单数据挂在根组件data.menuData上，在首页里用this.$parent.menuData获取。
另外，导航菜单很可能会有添加栏目图标的需求，这可以通过在路由中添加meta数据实现，例如将图标class或unicode存到路由meta里，模板中就可以访问到meta数据，用来生成图标标签。
在多角色系统中可能遇到的一个问题是，不同角色有一个名字相同但功能不同的路由，比如说系统管理员和企业管理员都有”账号管理”这个路由，但他们的操作权限和目标不同，实际上是两个完全不同的界面，而Vue不允许多个路由同名，因此路由的name必须做区分，但把区分后的name显示在前端菜单上会很不美观，为了让不同角色可以享有同一个菜单名称，我们只要将这两个路由的meta.name都设置成”账号管理”，在模板循环时优先使用meta.name就可以了。
菜单的具体实现可以参考views/index.vue。
视图控制
视图控制的目标是根据当前用户权限决定界面元素显示与否，典型场景是对各种操作按钮的显示控制。实现视图控制的本质是实现一个权限验证方法，输入请求权限，输出是否获准。然后配合v-if或jsx或自定义指令就能灵活实现各种视图控制。
全局验证方法
验证方法的的实现本身很简单，无非是根据后端给出的资源权限做判断，重点在于优化方法的输入输出，提升易用性，经过实践总结最终使用的方案是，将权限跟请求同时维护，验证方法接收请求对象数组为参数，返回是否具有权限的布尔值。
请求对象格式：
//获取账户列表 const request = { p: ['get,/accounts'], r: params => { return instance.get(`/accounts`, {params}) } }
权限验证方法$_has()的调用格式：
v-if="$_has([request])"
权限验证方法的具体实现见App.vue中Vue.prototype.$_has方法。
将权限验证方法全局混入，就可以在项目中很容易的配合v-if实现元素显示控制，这种方式的优点在于灵活，除了可以校验权限外，还可以在判断表达式中加入运行时状态做更多样性的判断，而且可以充分利用v-if响应数据变化的特点，实现动态视图控制。
具体实现细节参考基于Vue实现后台系统权限控制中的相关章节。
自定义指令
v-if的响应特性是把双刃剑，因为判断表达式在运行过程中会频繁触发，但实际上在一个用户会话周期内其权限并不会发生变化，因此如果只需要校验权限的话，用v-if会产生大量不必要的运算，这种情况只需在视图载入时校验一次即可，可以通过自定义指令实现：
//权限指令 Vue.directive('has', { bind: function(el, binding) { if (!Vue.prototype.$_has(binding.value)) { el.parentNode.removeChild(el); } } });
自定义指令内部仍然是调用全局验证方法，但优点在于只会在元素初始化时执行一次，多数情况下都应该使用自定义指令实现视图控制。
请求控制
请求控制是利用axios拦截器实现的，目的是将越权请求在前端拦截掉，原理是在请求拦截器中判断本次请求是否符合用户权限，以决定是否拦截。
普通请求的判断很容易，遍历后端返回的的资源权限格式，直接判断request.method和request.url是否吻合就可以了，对于带参数的url需要使用通配符，这里需要根据项目需求前后端协商一致，约定好通配符格式后，拦截器中要先将带参数的url处理成约定格式，再判断权限，方案中已经实现了以下两种通配符格式：