前后端分离开发中动态菜单的两种实现方案

关于前后端分离开发中的权限处理问题，松哥之前写过一篇文章和大家聊这个问题：

• Spring Boot + Vue 前后端分离开发，权限管理的一点思路

但是最近有小伙伴在学习微人事项目时，对动态菜单这一块还是有疑问（即不同用户登录成功后会看到不同的菜单项），因此松哥打算再来写一篇文章和大家聊一聊前后端分离开发中的动态菜单问题。

1. 一个原则

做权限管理，一个核心思想就是后端做权限控制，前端做的所有工作都只是为了提高用户体验，我们不能依靠前端展示或者隐藏一个按钮来实现权限控制，这样肯定是不安全的。

就像用户注册时需要输入邮箱地址，前端校验之后，后端还是要校验，两个校验目的不同，前端校验是为了提高响应速度，优化用户体验，后端校验则是为了确保数据完整性。权限管理也是如此，前端按钮的展示/隐藏都只是为了提高用户体验，真正的权限管理需要后端来实现。

这是非常重要的一点，做前后端分离开发中的权限管理，我们首先要建立上面这样的思考框架，然后在这样的框架下，去考虑其他问题。

因此，下文我会和大家分享两种方式实现动态菜单，这两种方式仅仅只是探讨如何更好的给用户展示菜单，而不是探讨权限管理，因为权限管理是在后端完成的，也必须在后端完成。

2. 具体实现

一旦建立起这样的思考框架，你会发现动态菜单的实现办法太多了。

动态菜单就是用户登录之后看到的菜单，不用角色的用户登录成功之后，会看到不用的菜单项，这个动态菜单要怎么实现呢？整体来说，有两种不同的方案，松哥曾经做过的项目中，两种方案也都有用过，这里分别来和大家分享一下。

2.1 后端动态返回

后端动态返回，这是我在微人事中采用的方案。微人事中，权限管理相关的表一共有五张表，如下：

其中 hr 表就是用户表，用户登录成功之后，可以查询到用户的角色，再根据用户角色去查询出来用户可以操作的菜单（资源），然后把这些可以操作的资源，组织成一个 JSON 数据，返回给前端，前端再根据这个 JSON 渲染出相应的菜单。以微人事为例，我们返回的 JSON 数据格式如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

[
    {
        "id":2,
        "path":"/home",
        "component":"Home",
        "name":"员工资料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":"EmpBasic",
                "name":"基本资料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]

这样的 JSON 在前端中再进行二次处理之后，就可以使用了，前端的二次处理主要是把 component 属性的字符串值转为对象。这一块具体操作大家可以参考微人事项目（具体在：https://github.com/lenve/vhr/blob/master/vuehr/src/utils/utils.js），我就不再赘述了。

这种方式的一个好处是前端的判断逻辑少一些，后端也不算复杂，就是一个 SQL 操作，前端拿到后端的返回的菜单数据，稍微处理一下就可以直接使用了。另外这种方式还有一个优势就是可以动态配置资源-角色以及用户-角色之间的关系，进而调整用户可以操作的资源(菜单)。

2.2 前端动态渲染

另一种方式就是前端动态渲染，这种方式后端的工作要轻松一些，前端处理起来麻烦一些，松哥去年年末帮一个律所做的一个管理系统，因为权限上比较容易，我就采用了这种方案。

这种方式就是我直接在前端把所有页面都在路由表里边定义好，然后在 meta 属性中定义每一个页面需要哪些角色才能访问，例如下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

[
    {
        "id":2,
        "path":"/home",
        "component":Home,
        "name":"员工资料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":EmpBasic,
                "name":"基本资料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true,
                    "roles":['admin','user']
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]

这样定义表示当前登录用户需要具备 admin 或者 user 角色，才可以访问 EmpBasic 组件，当然这里不是说我这样定义了就行，这个定义只是一个标记，在项目首页中，我会遍历这个数组做菜单动态渲染，然后根据当前登录用户的角色，再结合当前组件需要的角色，来决定是否把当前组件所对应的菜单项渲染出来。

这样的话，后端只需要在登录成功后返回当前用户的角色就可以了，剩下的事情则交给前端来做。不过这种方式有一个弊端就是菜单和角色的关系在前端代码中写死了，以后如果想要动态调整会有一些不方便，可能需要改代码。特别是大项目，权限比较复杂的时候，调整就更麻烦了，所以这种方式我一般建议在一些简单的项目中使用。

3. 结语

虽然我在微人事中使用了第一种方式，不过如果小伙伴是一个新项目，并且权限问题不是很复杂的话，我还是建议尝试一下第二种方式，感觉要方便一些。

不过在公司中，动态菜单到底在前端做还是后端做，可能会有一个前后端团队沟（si）通（bi）的过程，赢了的一方就可以少写几行代码了。