1. 登录之后到底发生了什么GetInfo 与 GenerateRouters 的整体设计很多人第一次接触若依前后端分离版本会觉得登录成功之后就“自动”有了菜单和按钮权限好像框架有魔法一样。实际上这背后是一条非常清晰的链路登录接口只负责发放 token真正决定你看到什么菜单、能点哪些按钮的是紧接着调用的两个接口——GetInfo和GenerateRouters。搞懂这两个接口基本就搞懂了若依权限体系的半壁江山。我在好几个基于若依二次开发的项目里踩过坑最常见的场景就是新来的同事把菜单配好了角色也分配了但前端死活不显示或者按钮权限明明加了v-hasPermi却怎么都拦不住。归根结底都是因为对这两个接口返回的数据结构、生成逻辑没有吃透。这篇文章我会把GetInfo获取用户角色和权限、GenerateRouters获取动态路由、以及首页数据加载这三块内容从头到尾拆一遍既讲清楚“为什么这么设计”也给出可以直接抄的排查方法和实操建议。这套机制适合所有正在使用若依前后端分离版本、或者准备基于它做二次开发的人。不管你是刚接手项目的新手还是已经改过几版权限逻辑的老手把这条链路理顺之后很多玄学问题都会变得有迹可循。2. GetInfo 接口深度拆解角色和权限究竟怎么查出来的2.1 接口入口与调用时机GetInfo对应的后端入口在SysLoginController里路径通常是/getInfo。它的调用时机很关键前端在登录拿到 token 之后会立刻带着这个 token 请求GetInfo。也就是说token 是敲门砖GetInfo才是真正把用户身份信息交给前端的接口。这个接口返回的数据大致长这样{ code: 200, user: { userId: 1, userName: admin, nickName: 若依, avatar: , roles: [admin], permissions: [*:*:*] }, roles: [admin], permissions: [*:*:*] }注意这里有一个容易被忽略的点user对象里也带了roles和permissions外层又重复了一份。这不是冗余设计失误而是历史兼容和前端不同取值习惯共同造成的。前端 store 里通常取外层的roles和permissions但有些自定义页面会直接从user对象里读。你自己写代码时建议统一取外层避免两边不一致时排查困难。2.2 权限标识是怎么被收集出来的GetInfo内部做的事情核心其实就两步查角色、查权限。角色通过用户 ID 去用户角色关联表里查权限则通过角色去菜单表里查对应的perms字段。我用一个更直白的方式解释这个过程。假设你给用户分配了“运营人员”这个角色这个角色关联了“文章管理”目录、“文章列表”菜单、“新增文章”按钮。那么角色查询会得到[operator]这样的角色标识集合。权限查询会把“文章列表”菜单的perms比如article:list和“新增文章”按钮的perms比如article:add全部拉出来组成权限集合。这里有个细节值得说明目录类型菜单的perms一般是空的因为它只负责分组不承载具体操作权限。真正产生权限标识的是菜单类型和按钮类型。如果你发现某个权限怎么都不生效先去菜单管理里看看那条记录的perms是不是空的或者是不是配成了目录。2.3 超级管理员的特殊处理若依对超级管理员做了硬编码处理。用户 ID 为 1 的 admin 用户返回的权限集合是[*:*:*]角色是[admin]。这个*:*:*是一个通配符前端在判断权限时会特殊放行。我在实际项目里遇到过有人把 admin 的用户 ID 改了结果权限全失效。这个 ID 判断是写死在代码里的不是通过角色标识判断的。如果你要做多管理员或者改超级管理员定义记得同步改这块逻辑否则会非常隐蔽地出问题。另外有些团队会在生产环境禁用 admin 账号改用普通账号加最高权限角色这时候那个*:*:*通配逻辑就用不上了所有权限都得老老实实配置。2.4 返回数据背后的缓存与性能考量GetInfo每次登录都会查一次数据库。对于菜单和角色数据变动不频繁的系统这个开销可以接受。但如果你的系统菜单特别多或者有大量按钮级权限每次查全量权限集合会有一定压力。我试过的一个优化方案是把角色的权限集合做一层本地缓存菜单或角色变更时主动失效。不过要注意缓存失效做不干净会导致权限改了不生效这比性能问题更让人头疼。如果你的系统规模不大我建议先不要加缓存等真正出现性能瓶颈再说。对于绝大多数中小型项目GetInfo的查询耗时都在可接受范围内。提示GetInfo里的权限集合是“当前用户所有角色权限的并集”。如果一个人有多个角色权限会合并去重。排查权限问题时先确认是不是多个角色叠加导致的预期外放行。3. GenerateRouters 动态路由后端怎么拼出前端菜单树3.1 从菜单表到路由对象的转换逻辑GenerateRouters是若依动态路由的核心。它的任务是把数据库里的菜单记录转换成前端 Vue Router 能识别的路由配置。这个转换过程主要在SysMenuServiceImpl的buildMenus方法里完成。一条菜单记录转换成路由对象时大致会映射这些字段path来自菜单的path字段。name来自菜单的routeName路由名称需要唯一。component来自菜单的component字段目录类型通常是Layout菜单类型是具体页面路径。meta里包含title、icon、noCache、link等信息。children是递归构建的子路由。这里最容易出问题的是component字段。目录必须用Layout菜单必须用实际的组件路径比如system/user/index如果配反了轻则页面白屏重则整个路由树挂掉。我在项目里见过有人把菜单的component写成了Layout结果点进去永远是个空壳。3.2 目录、菜单、按钮三种类型的差异化处理若依菜单表里有个menuType字段M 代表目录C 代表菜单F 代表按钮。buildMenus在处理时逻辑完全不同类型是否生成路由是否进菜单树典型 component目录 M是是Layout菜单 C是是具体页面组件按钮 F否否无按钮类型不会出现在路由里它只在GetInfo的权限集合里体现配合前端的v-hasPermi指令做按钮级控制。这就是为什么你新增一个按钮菜单后菜单树没变化但按钮权限生效了——它走的是另一条路。3.3 外链、内嵌与缓存路由的处理除了普通路由若依还支持几种特殊场景外链如果菜单的isFrame为 0 或者path是完整 URL会生成一个特殊路由点击后在浏览器新标签打开。实现上通常是通过InnerLink组件包一层 iframe。内嵌在系统内部以 iframe 形式打开外部页面菜单仍然在当前系统框架内。缓存控制meta.noCache决定页面是否被 keep-alive 缓存。默认菜单是不缓存的如果要缓存需要在菜单管理里设置“是否缓存”为缓存。我在实操中经常提醒团队外链的path如果是完整 URL前端的路由匹配要格外小心因为它和后端生成的component组合方式不同于普通菜单。配错了不会报错只会默默打不开。3.4 前端如何消费这些路由后端返回路由数组后前端的处理链路是这样的permission.js里的路由守卫在进入页面前拦截。如果 store 里还没有路由就调用GenerateRouters接口。拿到路由数据后通过router.addRoute动态注册。同时把路由数据存入 Vuex/Pinia供侧边栏渲染使用。这里有个经典坑动态路由添加后必须确保next({ ...to, replace: true })重新触发一次导航否则会出现刷新后白屏或者 404。因为第一次导航时路由还没注册完直接放行会匹配不到。// permission.js 里的关键片段 const accessRoutes await store.dispatch(permission/generateRoutes, roles) accessRoutes.forEach(route { router.addRoute(route) }) next({ ...to, replace: true })这段代码里replace: true很重要它避免在浏览器历史里留下一条无效记录。我见过有人漏了这句用户点后退会回到一个空白页体验很差。4. 首页数据加载从路由就绪到内容渲染的完整链路4.1 首页组件挂载后的请求时机动态路由注册完成、用户进入首页之后首页组件通常是index.vue开始挂载。这时候才轮到首页数据加载登场。它的时机在动态路由之后因为首页本身也是动态路由的一部分路由没就绪组件根本不会渲染。首页数据加载一般分两类一类是框架自带的统计卡片、版本信息等另一类是业务自定义的看板数据。框架自带的部分通常写死在首页组件里业务看板则需要你自己在created或mounted里发起请求。我建议的做法是把首页数据请求统一放在mounted里并用Promise.all并行发起避免多个请求串行导致的加载缓慢。如果某个数据块加载失败用错误边界包起来不要让整页崩掉。4.2 常见首页数据源的接入方式我在几个项目里接过的首页数据源主要有这几类统计接口返回用户数、订单数、文章数等汇总值。通常单独提供一个/dashboard/stats之类的接口。图表数据折线图、柱状图的数据集合一般和图表库配合使用。通知公告从公告表里拉最新几条展示在首页角落。待办事项根据当前用户角色过滤出的待处理任务。这里有个实操心得首页接口不要和GetInfo混在一起。有人图省事把统计数字塞进GetInfo的返回里结果导致登录变慢而且缓存和权限逻辑搅在一起后面很难维护。首页数据该独立就独立。4.3 首页加载与权限的联动首页上如果也有按钮级操作同样受GetInfo返回的权限集合控制。比如“导出报表”按钮如果当前用户没有dashboard:export权限就应该隐藏。这部分的判断和普通页面完全一致用v-hasPermi即可。需要注意的是首页的权限判断发生在数据加载之前还是之后会影响用户体验。如果先加载数据再判断权限用户可能看到一瞬间的按钮闪现。我的做法是先用权限指令控制渲染数据请求照常发起两者互不阻塞。5. 常见问题与排查技巧实录5.1 菜单不显示、路由丢失的排查路径这是最高频的问题。我的排查顺序通常是先看GetInfo返回的角色和权限是否正确。如果角色为空说明用户角色关联没配好。再看GenerateRouters返回的路由数组是否为空。为空通常是菜单没有分配给角色或者菜单状态是停用。检查菜单的component字段。目录必须是Layout菜单必须是真实组件路径。检查路由name是否重复。重复的name会导致后注册的覆盖先注册的。检查前端控制台有没有addRoute相关的警告。我整理了一个速查表现象可能原因快速验证菜单完全为空角色未分配菜单查角色菜单关联表某个菜单缺失菜单状态停用或隐藏查菜单 visible/status点击菜单白屏component 路径错误比对组件实际路径刷新后 404动态路由未重新注册查 permission.js 逻辑按钮权限失效perms 字段为空或拼写错误查菜单 perms 字段5.2 权限标识不生效的典型原因按钮权限不生效八成是这几个原因之一perms字段拼写和前端v-hasPermi里的字符串不一致权限集合被多个角色叠加后没有正确去重或者前端缓存了旧的权限数据退出重登才生效。我踩过最深的一个坑是修改了角色的权限后当前在线用户的权限不会实时刷新。因为权限是在登录时一次性拉取的。如果业务要求实时生效需要额外的刷新机制比如提供手动刷新权限的入口或者用 websocket 推送变更。大多数项目其实不需要这么复杂重新登录即可。5.3 首页白屏与数据不加载的处理首页白屏通常不是首页本身的问题而是动态路由链路出了问题。我的经验是先确认路由是否注册成功再看首页组件是否被正确匹配。可以在permission.js里加日志打印出最终注册的路由列表。如果首页能显示但数据不加载检查请求是否被权限拦截、接口路径是否正确、以及是否有跨域问题。前后端分离部署时跨域和网关转发是高频故障点。注意动态路由的调试建议在开发环境打开 Vue DevTools 的路由面板能直观看到注册了哪些路由。生产环境排查则主要靠后端接口返回和前端控制台。6. 我在实际项目里的一些体会这套 GetInfo 加 GenerateRouters 的组合用顺了之后其实非常省心。我个人的体会是二次开发时尽量不要去动这两个接口的核心结构而是通过扩展菜单字段、增加自定义权限标识来满足需求。一旦改了返回结构前端 store、路由守卫、权限指令都得跟着改牵一发动全身。另外一个小技巧如果你需要给某些页面加“仅特定角色可见”的逻辑除了用权限标识还可以在路由meta里塞自定义角色字段在路由守卫里统一判断。这样比在每个页面里写判断要清爽得多。首页数据加载这块我倾向于把请求封装成独立的 service 层首页组件只负责调用和渲染后续要换数据源或者加缓存都方便。最后再提一句若依的这套机制本质上就是“登录拿 tokentoken 换身份身份换路由路由驱动页面”。把这四步的每一步都验证清楚任何权限和菜单问题都能顺藤摸瓜找到根因。
若依权限体系：GetInfo与GenerateRouters动态路由
1. 登录之后到底发生了什么GetInfo 与 GenerateRouters 的整体设计很多人第一次接触若依前后端分离版本会觉得登录成功之后就“自动”有了菜单和按钮权限好像框架有魔法一样。实际上这背后是一条非常清晰的链路登录接口只负责发放 token真正决定你看到什么菜单、能点哪些按钮的是紧接着调用的两个接口——GetInfo和GenerateRouters。搞懂这两个接口基本就搞懂了若依权限体系的半壁江山。我在好几个基于若依二次开发的项目里踩过坑最常见的场景就是新来的同事把菜单配好了角色也分配了但前端死活不显示或者按钮权限明明加了v-hasPermi却怎么都拦不住。归根结底都是因为对这两个接口返回的数据结构、生成逻辑没有吃透。这篇文章我会把GetInfo获取用户角色和权限、GenerateRouters获取动态路由、以及首页数据加载这三块内容从头到尾拆一遍既讲清楚“为什么这么设计”也给出可以直接抄的排查方法和实操建议。这套机制适合所有正在使用若依前后端分离版本、或者准备基于它做二次开发的人。不管你是刚接手项目的新手还是已经改过几版权限逻辑的老手把这条链路理顺之后很多玄学问题都会变得有迹可循。2. GetInfo 接口深度拆解角色和权限究竟怎么查出来的2.1 接口入口与调用时机GetInfo对应的后端入口在SysLoginController里路径通常是/getInfo。它的调用时机很关键前端在登录拿到 token 之后会立刻带着这个 token 请求GetInfo。也就是说token 是敲门砖GetInfo才是真正把用户身份信息交给前端的接口。这个接口返回的数据大致长这样{ code: 200, user: { userId: 1, userName: admin, nickName: 若依, avatar: , roles: [admin], permissions: [*:*:*] }, roles: [admin], permissions: [*:*:*] }注意这里有一个容易被忽略的点user对象里也带了roles和permissions外层又重复了一份。这不是冗余设计失误而是历史兼容和前端不同取值习惯共同造成的。前端 store 里通常取外层的roles和permissions但有些自定义页面会直接从user对象里读。你自己写代码时建议统一取外层避免两边不一致时排查困难。2.2 权限标识是怎么被收集出来的GetInfo内部做的事情核心其实就两步查角色、查权限。角色通过用户 ID 去用户角色关联表里查权限则通过角色去菜单表里查对应的perms字段。我用一个更直白的方式解释这个过程。假设你给用户分配了“运营人员”这个角色这个角色关联了“文章管理”目录、“文章列表”菜单、“新增文章”按钮。那么角色查询会得到[operator]这样的角色标识集合。权限查询会把“文章列表”菜单的perms比如article:list和“新增文章”按钮的perms比如article:add全部拉出来组成权限集合。这里有个细节值得说明目录类型菜单的perms一般是空的因为它只负责分组不承载具体操作权限。真正产生权限标识的是菜单类型和按钮类型。如果你发现某个权限怎么都不生效先去菜单管理里看看那条记录的perms是不是空的或者是不是配成了目录。2.3 超级管理员的特殊处理若依对超级管理员做了硬编码处理。用户 ID 为 1 的 admin 用户返回的权限集合是[*:*:*]角色是[admin]。这个*:*:*是一个通配符前端在判断权限时会特殊放行。我在实际项目里遇到过有人把 admin 的用户 ID 改了结果权限全失效。这个 ID 判断是写死在代码里的不是通过角色标识判断的。如果你要做多管理员或者改超级管理员定义记得同步改这块逻辑否则会非常隐蔽地出问题。另外有些团队会在生产环境禁用 admin 账号改用普通账号加最高权限角色这时候那个*:*:*通配逻辑就用不上了所有权限都得老老实实配置。2.4 返回数据背后的缓存与性能考量GetInfo每次登录都会查一次数据库。对于菜单和角色数据变动不频繁的系统这个开销可以接受。但如果你的系统菜单特别多或者有大量按钮级权限每次查全量权限集合会有一定压力。我试过的一个优化方案是把角色的权限集合做一层本地缓存菜单或角色变更时主动失效。不过要注意缓存失效做不干净会导致权限改了不生效这比性能问题更让人头疼。如果你的系统规模不大我建议先不要加缓存等真正出现性能瓶颈再说。对于绝大多数中小型项目GetInfo的查询耗时都在可接受范围内。提示GetInfo里的权限集合是“当前用户所有角色权限的并集”。如果一个人有多个角色权限会合并去重。排查权限问题时先确认是不是多个角色叠加导致的预期外放行。3. GenerateRouters 动态路由后端怎么拼出前端菜单树3.1 从菜单表到路由对象的转换逻辑GenerateRouters是若依动态路由的核心。它的任务是把数据库里的菜单记录转换成前端 Vue Router 能识别的路由配置。这个转换过程主要在SysMenuServiceImpl的buildMenus方法里完成。一条菜单记录转换成路由对象时大致会映射这些字段path来自菜单的path字段。name来自菜单的routeName路由名称需要唯一。component来自菜单的component字段目录类型通常是Layout菜单类型是具体页面路径。meta里包含title、icon、noCache、link等信息。children是递归构建的子路由。这里最容易出问题的是component字段。目录必须用Layout菜单必须用实际的组件路径比如system/user/index如果配反了轻则页面白屏重则整个路由树挂掉。我在项目里见过有人把菜单的component写成了Layout结果点进去永远是个空壳。3.2 目录、菜单、按钮三种类型的差异化处理若依菜单表里有个menuType字段M 代表目录C 代表菜单F 代表按钮。buildMenus在处理时逻辑完全不同类型是否生成路由是否进菜单树典型 component目录 M是是Layout菜单 C是是具体页面组件按钮 F否否无按钮类型不会出现在路由里它只在GetInfo的权限集合里体现配合前端的v-hasPermi指令做按钮级控制。这就是为什么你新增一个按钮菜单后菜单树没变化但按钮权限生效了——它走的是另一条路。3.3 外链、内嵌与缓存路由的处理除了普通路由若依还支持几种特殊场景外链如果菜单的isFrame为 0 或者path是完整 URL会生成一个特殊路由点击后在浏览器新标签打开。实现上通常是通过InnerLink组件包一层 iframe。内嵌在系统内部以 iframe 形式打开外部页面菜单仍然在当前系统框架内。缓存控制meta.noCache决定页面是否被 keep-alive 缓存。默认菜单是不缓存的如果要缓存需要在菜单管理里设置“是否缓存”为缓存。我在实操中经常提醒团队外链的path如果是完整 URL前端的路由匹配要格外小心因为它和后端生成的component组合方式不同于普通菜单。配错了不会报错只会默默打不开。3.4 前端如何消费这些路由后端返回路由数组后前端的处理链路是这样的permission.js里的路由守卫在进入页面前拦截。如果 store 里还没有路由就调用GenerateRouters接口。拿到路由数据后通过router.addRoute动态注册。同时把路由数据存入 Vuex/Pinia供侧边栏渲染使用。这里有个经典坑动态路由添加后必须确保next({ ...to, replace: true })重新触发一次导航否则会出现刷新后白屏或者 404。因为第一次导航时路由还没注册完直接放行会匹配不到。// permission.js 里的关键片段 const accessRoutes await store.dispatch(permission/generateRoutes, roles) accessRoutes.forEach(route { router.addRoute(route) }) next({ ...to, replace: true })这段代码里replace: true很重要它避免在浏览器历史里留下一条无效记录。我见过有人漏了这句用户点后退会回到一个空白页体验很差。4. 首页数据加载从路由就绪到内容渲染的完整链路4.1 首页组件挂载后的请求时机动态路由注册完成、用户进入首页之后首页组件通常是index.vue开始挂载。这时候才轮到首页数据加载登场。它的时机在动态路由之后因为首页本身也是动态路由的一部分路由没就绪组件根本不会渲染。首页数据加载一般分两类一类是框架自带的统计卡片、版本信息等另一类是业务自定义的看板数据。框架自带的部分通常写死在首页组件里业务看板则需要你自己在created或mounted里发起请求。我建议的做法是把首页数据请求统一放在mounted里并用Promise.all并行发起避免多个请求串行导致的加载缓慢。如果某个数据块加载失败用错误边界包起来不要让整页崩掉。4.2 常见首页数据源的接入方式我在几个项目里接过的首页数据源主要有这几类统计接口返回用户数、订单数、文章数等汇总值。通常单独提供一个/dashboard/stats之类的接口。图表数据折线图、柱状图的数据集合一般和图表库配合使用。通知公告从公告表里拉最新几条展示在首页角落。待办事项根据当前用户角色过滤出的待处理任务。这里有个实操心得首页接口不要和GetInfo混在一起。有人图省事把统计数字塞进GetInfo的返回里结果导致登录变慢而且缓存和权限逻辑搅在一起后面很难维护。首页数据该独立就独立。4.3 首页加载与权限的联动首页上如果也有按钮级操作同样受GetInfo返回的权限集合控制。比如“导出报表”按钮如果当前用户没有dashboard:export权限就应该隐藏。这部分的判断和普通页面完全一致用v-hasPermi即可。需要注意的是首页的权限判断发生在数据加载之前还是之后会影响用户体验。如果先加载数据再判断权限用户可能看到一瞬间的按钮闪现。我的做法是先用权限指令控制渲染数据请求照常发起两者互不阻塞。5. 常见问题与排查技巧实录5.1 菜单不显示、路由丢失的排查路径这是最高频的问题。我的排查顺序通常是先看GetInfo返回的角色和权限是否正确。如果角色为空说明用户角色关联没配好。再看GenerateRouters返回的路由数组是否为空。为空通常是菜单没有分配给角色或者菜单状态是停用。检查菜单的component字段。目录必须是Layout菜单必须是真实组件路径。检查路由name是否重复。重复的name会导致后注册的覆盖先注册的。检查前端控制台有没有addRoute相关的警告。我整理了一个速查表现象可能原因快速验证菜单完全为空角色未分配菜单查角色菜单关联表某个菜单缺失菜单状态停用或隐藏查菜单 visible/status点击菜单白屏component 路径错误比对组件实际路径刷新后 404动态路由未重新注册查 permission.js 逻辑按钮权限失效perms 字段为空或拼写错误查菜单 perms 字段5.2 权限标识不生效的典型原因按钮权限不生效八成是这几个原因之一perms字段拼写和前端v-hasPermi里的字符串不一致权限集合被多个角色叠加后没有正确去重或者前端缓存了旧的权限数据退出重登才生效。我踩过最深的一个坑是修改了角色的权限后当前在线用户的权限不会实时刷新。因为权限是在登录时一次性拉取的。如果业务要求实时生效需要额外的刷新机制比如提供手动刷新权限的入口或者用 websocket 推送变更。大多数项目其实不需要这么复杂重新登录即可。5.3 首页白屏与数据不加载的处理首页白屏通常不是首页本身的问题而是动态路由链路出了问题。我的经验是先确认路由是否注册成功再看首页组件是否被正确匹配。可以在permission.js里加日志打印出最终注册的路由列表。如果首页能显示但数据不加载检查请求是否被权限拦截、接口路径是否正确、以及是否有跨域问题。前后端分离部署时跨域和网关转发是高频故障点。注意动态路由的调试建议在开发环境打开 Vue DevTools 的路由面板能直观看到注册了哪些路由。生产环境排查则主要靠后端接口返回和前端控制台。6. 我在实际项目里的一些体会这套 GetInfo 加 GenerateRouters 的组合用顺了之后其实非常省心。我个人的体会是二次开发时尽量不要去动这两个接口的核心结构而是通过扩展菜单字段、增加自定义权限标识来满足需求。一旦改了返回结构前端 store、路由守卫、权限指令都得跟着改牵一发动全身。另外一个小技巧如果你需要给某些页面加“仅特定角色可见”的逻辑除了用权限标识还可以在路由meta里塞自定义角色字段在路由守卫里统一判断。这样比在每个页面里写判断要清爽得多。首页数据加载这块我倾向于把请求封装成独立的 service 层首页组件只负责调用和渲染后续要换数据源或者加缓存都方便。最后再提一句若依的这套机制本质上就是“登录拿 tokentoken 换身份身份换路由路由驱动页面”。把这四步的每一步都验证清楚任何权限和菜单问题都能顺藤摸瓜找到根因。
