企业官网建设流程全解析

拿到这个标题，我得先说实话，动态菜单路由这块是若依前后端分离版里最绕、但也最值得搞明白的一段。很多初学者一开始觉得它神秘，无非是因为它不像普通项目那样在代码里把路由写死，而是等用户登录以后，根据后端返回的菜单数据临时“拼”出一套路由来。这背后牵扯到数据库表、后端查询逻辑、Vuex状态管理、Vue Router动态注册好几个环节，任何一个环节脱节，表现出来的就是刷新页面就白屏，或者菜单半天出不来。这篇文章我就围绕“获取动态菜单路由”这条主线，把若依的前后端配合逻辑掰开揉碎讲清楚，包括后端到底返回了什么、前端拿到数据以后做了什么处理、路由是怎么动态挂载的，以及我实际开发中踩过的一堆坑。

先说清楚这套机制到底解决了什么问题。大部分管理系统权限模型是固定的，谁的账号进来就看到那么几套页面，权限控制基本靠前端页面显示隐藏来做。但若依不是这样玩，它的菜单、按钮权限全部存数据库，用户登录后系统根据用户身份动态决定他能看到哪些菜单、进入哪些页面。这就是“动态菜单路由”存在的意义：菜单不是写死在代码里的，而是服务端下发、前端渲染。也就是说，同一套前端工程，配置不同的角色权限，登录后看到的界面可以完全不一样。

1. 搞懂若依动态路由的前后端设计思路

1.1 动态菜单路由到底是怎么个动态法

要理解若依的动态菜单路由，首先要跳出普通 Vue 项目的思维定势。普通项目通常在router/index.js里把首页、列表页、详情页全部定义好，用户访问哪个路径就渲染哪个组件。若依的做法完全不同：它把菜单结构存到了数据库的sys_menu表里，每个菜单还带上了菜单类型、路由地址、组件路径、权限标识、显隐状态、排序等一堆字段。

用户登录以后，后端会根据当前用户所拥有的角色，去sys_menu里查询出他能访问的菜单，然后返回一棵符合前端路由要求的结构树。前端拿到这棵树之后，再通过 Vue Router 的addRoute方法把这些路由“塞”进路由表。这个过程就是动态路由的完整闭环。

这里要注意，若依动态菜单路由和简单的“按角色加载不同菜单”有本质区别。它不只是控制菜单的可见性，而是整套前端路由表本身就是运行时生成的。后端给什么菜单，前端就注册什么路由。哪怕两个用户登录的是同一个前端工程，他们所能访问到的 URL 也是不一样的——没有权限的路径，在路由表里压根就不存在。

1.2 为什么费这么大劲，直接把路由全部注册不行吗

很多人一开始会问：我把所有路由全部注册进去，菜单上不显示不就好了？这样后端都不用返回菜单了，不是更省事吗？

这个问题的答案是：能省事，但会埋下安全隐患。前端路由无法真正保护后端接口，只做页面级隐藏只是掩耳盗铃。如果一个没有权限的用户猜到了管理后台某个 URL，直接输入地址访问，前端路由完全匹配得到，页面就渲染出来了，页面里就会正常执行请求后端的操作。而若依的动态路由机制，没有权限的页面根本不在路由表里，用户直接改 URL 访问，Vue Router 直接就报没有匹配到的 404 了。

所以在若依的设计里，动态路由和动态菜单是同一套机制在支撑。前端侧保障的是“看不到也进不去”，后端侧保障的是“接口访问会被拦截”，两层配合才是完整权限体系。如果你把前端路由写死，那就等于放弃了一层重要的防线，也放弃了这个脚手架最核心的设计思想。

1.3 若依菜单表的字段含义，先看再理解

后端返回的数据，本质上就是sys_menu表里的记录组装而成的。你要真正理解前端为什么这样处理数据，必须先认识这张表的关键字段。我直接挑重点说明。

这里最关键的字段是component。前端就是根据这个字段去加载对应组件的。目录类型通常是Layout，菜单类型的component则指向具体的 Vue 组件路径，比如system/user/index就对应前端views/system/user/index.vue这个文件。

2. 后端接口返回了什么，动态路由的数据源头

2.1 获取路由的核心接口 /getRouters

若依前后端分离版中，后端获取动态路由的接口路径一般是/getRouters，完整路由通常是/getRouters，由SysLoginController或SysMenuController暴露。前端调用的地址在接口封装文件里通常写成/getRouters。前端请求这个接口时，请求头会带上登录后的 token，后端根据 token 解析出当前登录用户，再查询该用户拥有的菜单权限。

这个接口返回的结构是嵌套树形结构，父菜单下有 children，子菜单还有 children，依次递归。前端通过递归的方式来处理这套数据，最终转换成 Vue Router 能识别的路由表结构。返回数据的核心部分大致是这样的结构：

{ "code": 200, "data": { "menus": [ { "name": "System", "path": "/system", "component": "Layout", "meta": {"title": "系统管理", "icon": "system", "isLink": null}, "children": [ { "name": "User", "path": "user", "component": "system/user/index", "meta": {"title": "用户管理", "icon": "user", "isLink": null} } ] } ] } }

从这里可以看到两个关键点：第一，menus是一个数组，代表了最终渲染菜单树的顶层节点；第二，数据的结构设计刻意贴合了前端路由的概念，path、component、name这些字段和 Vue Router 的路由配置高度对齐。也就是说，后端返回的数据已经为前端做路由转换做好了准备。

2.2 后端权限查询的逻辑简述

后端层面，权限数据是围绕角色来组织的。一个用户可能拥有多个角色，一个角色可能关联多个菜单。用户登录时后端只存了一个登录标记，也就是 token，后续每次请求都通过 token 去查这个用户是谁。在/getRouters这个接口里，后端会根据用户 ID 去sys_user_role、sys_role_menu、sys_menu这些关联表里查这个用户能看的所有菜单。查询出来的菜单会经过一次排序、组装，构建成树形结构返回给前端。如果你自己改了数据库里的菜单数据，刷新页面后，前端拿到的动态菜单就会跟着变化。这就是这套框架权限管理灵活的地方。

2.3 为什么后端姓“菜单”而不是姓“路由”

看代码时你可能会好奇，为什么后端的表叫sys_menu，返回的数据结构却叫路由结构。这其实是若依的一个设计特色：菜单表和路由信息混在一起存储，菜单天然就携带了前端路由需要的字段。

这样做的好处很明显，管理后台可以在同一个菜单管理界面里既维护前端路由，又维护页面标题、图标、权限标识，甚至还能维护按钮级别的权限点。在菜单管理中维护好路由信息，前端就不需要再为权限页面单独维护一套路由映射表了。

但这也带来了一个容易让人困惑的点：前端代码里找不到完整的路由表。如果你非要在前端代码里找某个页面的路由配置，你最终会找到permission.js里从接口拉取菜单、动态注册路由的逻辑，而不是某一个现成的路由数组。理解了这一点，你才算真正入门了这套动态路由机制。

3. 前端获取动态菜单路由的完整链路

3.1 路由守卫里发生了什么

前端动态路由的起点不在页面组件里，而在src/permission.js这个文件里。这个文件注册了一个全局前置守卫，只要路由发生变化，这个守卫就会先执行。重点逻辑大致是这样的：

先判断有没有 token。没有 token，说明用户还没有登录，那就直接跳转到登录页。有 token，再判断用户信息是否已经拉取过。如果还没有，就进入“加载用户信息+动态路由”的流程。

这个流程里最关键的一步是调用 Vuex 里的GenerateRoutes（注意不同版本方法名有细微差别），这个方法会发起/getRouters请求，拿到当前用户的菜单数据后，会用一个递归方法把它转换成 Vue Router 需要的路由配置格式，然后通过router.addRoutes或者新版 Vue Router 的addRoute逐个注册进去。

3.2 Vuex里权限模块的角色

若依的 Vuex 里专门有一个permission模块，用来管理路由侧的数据。这个模块中有两个相当重要的概念，一个是动态路由转换方法，另一个是保存最终路由结果的 state。

permission模块会暴露一个状态数据routes，这个数据用于侧边栏菜单渲染；还有一个dynamicRoutes，用于保存动态注册的路由。前端侧边栏组件并不直接读取动态路由注册的结果，而是读取 Vuex 里的routes数据来渲染菜单。这么做的好处是菜单渲染和路由注册虽然来源一致，但数据流是分开的，互不干扰。

在这里我想重点强调一下，addRoute注册的是路由，而 Vuex 里存的是菜单数据。两者有关系，但不是一回事。路由注册上去以后，浏览器地址栏输入对应 URL 能访问；菜单渲染逻辑是另外一套，根据 Vuex 里的routes生成侧边栏列表。如果你做二次开发时自定义了路由结构，一定要保证这两份数据保持一致，否则可能出现菜单不显示、但输入 URL 能访问的情况，UI 和权限就出现矛盾了。

3.3 路由转换的核心逻辑剖析

若依前端代码里最容易被拿来二次改造的就是路由转换的逻辑。后端返回的菜单结构是嵌套的，前端要先拿到这个结构，然后做一次映射，把标准的菜单树转成 Vue Router 能识别的路由配置。

转换逻辑的核心代码风格大概是这样：

function loadView(view) { return (resolve) => require([`@/views/${view}`], resolve) }

这段代码是动态路由加载组件的关键。如果component是Layout，需要映射成Layout组件；如果是普通页面路径，就通过loadView动态加载对应的 .vue 文件。这里的@/views/前缀说明，后端配置的组件路径需要和前端src/views目录结构保持一致。

实际转换时遍历的是树形结构，逐层判断。每个菜单会生成一个路由对象，path直接取菜单的path字段，name取菜单名，meta里存放标题、图标、是否外链等信息。对于目录类型M，组件映射为Layout；对于菜单类型C，组件映射为Layout/或者具体的页面组件。这个细节有很多坑，我在后面章节详细展开。

4. 菜单路由拿到手之后，页面是怎么渲染出来的

4.1 侧边栏组件的数据来源

侧边栏菜单的渲染入口在布局组件Layout里，它引用了Sidebar子组件，而Sidebar的核心数据来源就是 Vuex 中permission模块的routes。这是菜单渲染和数据流最直接的联系。

Sidebar组件内部使用递归组件SidebarItem对routes做遍历渲染。每遍历到一个父子节点，就渲染出对应的菜单项。如果是外链isLink，就以链接形式打开；如果有子菜单，就递归渲染子菜单。所以你在页面上看到的多级菜单，本质上就是 Vuex 里的routes数据生成的。

这里有一个很实用的排查技巧：如果你改了数据库菜单但前端页面没变化，先去浏览器控制台里打印 Vuex 的permission/routes，看看到底拿到的是什么数据。很快就能定位问题出在后端返回还是前端转换。这种排查方式比看代码猜要快得多。

4.2 动态路由注册成功与组件渲染的关系

路由最终能访问，起决定性作用的是router.addRoute这个动作。每次动态注册一个路由时，Vue Router 都会把路由加入路由匹配表。这之后用户在地址栏输入对应路径，Vue Router 才能匹配到对应的组件并渲染。

这里有一个容易忽视的细节：动态路由注册之后，如果你马上用router.push跳转到对应页面，可能第一次跳转失败。原因是路由解析时动态路由尚未注册完成，或者异步回调没有落到正确的时机。若依源码在路由守卫里做了处理，保证菜单拉取和路由注册完成后再放行跳转。

我在自己项目里遇到过一种情况，就是在GenerateRoutes这个 action 还有异步操作没完成时，前端就提前调用next()，导致刷新页面后动态路由还没有注册上去，页面却已经结束了守卫流程，最终白屏或 404。这个问题的典型表现就是：第一次进系统一切正常，F5 刷新之后菜单就消失了或者跳转 404 了。排查思路非常明确，直接在路由守卫里打点，看是异步请求未完成就放行了，还是addRoute没执行到。

4.3 404页面为什么容易踩坑

若依的动态路由里有个经典坑位：404 页面的路由位置。如果你把 404 路由定义在静态路由表里，同时动态路由又还没有注册完，刷新一个深层页面时很可能先匹配到 404，而不是你期望的实际页面。

若依框架处理这个问题的思路是，在动态路由的最末尾追加一个 catch-all 路由{ path: '*', redirect: '/404' }，这样等动态路由全部注册完，它才会匹配最终结果，避免提前拦截。这个细节在二次开发时特别重要。如果你自己往路由表里加了路由，却始终进不去页面，一直停在 404，大部分情况下是 catch-all 路由的位置不对，或者动态路由注册顺序不对。

我自己使用的是在动态路由生成的函数里，最后返回一个 catch-all 路由节点，确保它排在最末尾。这种做法在若依原版代码里就是这样设计的，二次开发时千万别手欠把这个逻辑给删了。

5. 实操中常见的问题与排查

5.1 刷新页面之后动态路由丢失怎么办

这是若依动态路由最常遇到的面试题和实战坑。刷新页面后，前端的 Vuex 状态会全部清空，也就是所有异步拉取的数据都没了。如果没有重新拉取菜单和动态注册路由，那浏览器在地址栏里带着路径刷新，就会找不到对应路由。

解决方案就在路由守卫里：它通过 token 和用户信息判断用户是否已经“登录过”，如果用户信息不存在，但存在 token，说明是刷新场景，就重新拉取用户信息和动态路由。保证刷新的时候把动态路由再次注册进去。

我实际排查时发现，很多刷新 404 的案例并不是框架逻辑问题，而是项目里的某个自定义组件抛了异常，导致路由守卫后续代码没有执行完。因此遇到刷新白屏，先打开控制台看报错，不要一股脑认定是路由问题。

5.2 动态菜单拿到了，但组件加载报错

这种情况一般出现在后端配置菜单时，component字段写错了。比如前端组件实际存放在views/system/user/index.vue，后端却写成了system/user，那require加载就会失败。或者文件路径大小写不匹配，Linux 服务器环境下会直接报找不到模块的错误。

排查方式就是直接看浏览器控制台的精确报错信息，提示哪个文件加载失败，然后去src/views下核对路径和文件名。还有一点，组件的名称要尽量和路由 name 一致，否则配合 keep-alive 时缓存会失效，页面状态保存不住。

5.3 多级菜单和组件路径参考 Layout 的特殊处理

若依菜单管理的顶级菜单组件路径一般填Layout，二级菜单的component才会指向真实页面。这个设计需要特别注意：如果你在后端配置一个三级菜单，但component没有指向具体的页面组件，而是又填了Layout，前端渲染可能就不会按预期工作。

多级目录这种场景，父级目录的component固定是Layout，子目录往下走，每一层目录如果你也想渲染一个布局壳子，那就需要自行创建对应的布局组件，然后在后端菜单里配置对应的路径。如果你现在只是做业务开发，不搞复杂的嵌套布局，最简单的方式就是尽量控制菜单层级，保持在两级，第三级就放页面。

一个更稳妥的做法是：页面配置好以后，先在本地把菜单路径和前端目录结构核对清楚，再保存到数据库里，避免线上反反复复调试菜单。

5.4 按钮权限如何配合动态路由使用

动态菜单解决的是“用户能看到哪些页面”的问题，按钮权限解决的是“用户能在这个页面里操作哪些按钮”的问题。若依的按钮权限和菜单权限同样存储在sys_menu表，区别只是menu_type为 F。前端通过自定义指令v-hasPermi根据权限标识控制按钮的显示隐藏，而这些权限标识也需要在用户信息加载时一并获取。

如果你在二次开发时发现按钮权限没有生效，先看在用户信息接口里返回的permissions字段是否包含了对应的按钮权限标识。如果后端没返回，前端再怎么判断也没有用。前后端权限体系是联动的，单端排查很难解决问题。

6. 个人实操中的一点心得与技巧

我前前后后基于若依做过几个管理系统，对动态菜单路由的理解也是一步步踩坑踩出来的。最后说几个我认为能在实际开发中提高效率的使用习惯。

第一个心得，强烈建议在开发环境打开 Vue Devtools 的 Vuex 选项卡，动态路由流程走一遍，亲眼看一下permission模块里数据的变化。这比读源码直观多了。你会看到登录后routes从空数组变成一堆路由配置，那种感觉就是一下子通了。

第二个心得，尽量规范数据库菜单配置，path统一用驼峰或短横线风格，component统一以前端路径为准，所有维护菜单的人都要遵守同一份约定。多人协作时菜单配置混乱是最大的隐性成本。

第三个心得，动态路由的二次开发大概率不是去改它的“动态”部分，而是去扩展你业务自己的路由和权限点。这时候核心思路是：先加菜单记录进数据库，再确保前端views目录下有对应组件，最后让权限分配给角色。如果你因为这个流程导致菜单不显示，别慌，路由守卫和 Vuex 的数据链路仔细走一遍，很快就能定位到哪一步断了。

还有个非常实用的小技巧：在开发阶段后端接口挂了，常导致登录后一片空白，很容易误判成前端问题。可以先在浏览器的 Network 面板确认/getRouters接口是否返回正常，先解决后端问题，再回来调前端。很多初学者一看到白屏就怀疑动态路由出了问题，其实大多数情况是网络请求挂掉了。

第四个心得，若依的动态菜单路由在前后端分离场景下，本质上是把权限模型和 Vue Router 的运行时机制做了深度的绑定。做二次开发时，如果不能完全驾驭这套机制，宁可先沿用它的规则，也不要轻易另起炉灶。我有一次为了做一个特殊布局，把动态路由的生成逻辑改得面目全非，结果后续所有菜单调整都要靠改代码完成，数据库里配菜单反而没用了，效率严重下降。后来我放弃了自定义方案，回归到若依的标准流程，把布局差异通过组件内部样式解决。路由就用标准方式生成，这才是更高效的路子。