摘要：为用户进行设置角色，登陆系统后，用户可使用其拥有角色对应的所有菜单。负责后台用户的菜单授权。这里仅实现了菜单的隐藏，需要再编写权限控制逻辑，使我们的系统更安全，但那是我们以后要考虑的事情。
问题描述
动态菜单管理，用户对应角色，角色对应菜单。
为用户进行设置角色，登陆系统后，用户可使用其拥有角色对应的所有菜单。
功能实现很简单，这里就不进行代码的讲解了，直接讲一下我所实现的思路。
实现 原设计系统设置中，前台菜单遵循如下格式：
menus: [
{
text: "主导航",
group: true,
children: [
{
text: "首页",
link: "/main",
icon: "anticon anticon-compass"
},
{
text: "系统设置",
link: "/setting",
icon: "anticon anticon-setting"
}
],
}
]
所以最开始的思路也很简单，后台的Menu实体中存储菜单所有相关的信息。
后台直接就查出当前登录用户所有的菜单，前台根据返回来的菜单数据构建前台菜单。
问题能实现肯定是能实现，但我们进行设计时，考虑的不应仅仅是实现，考虑的更多的是我这么实现，效率高不高？以后好不好改？能不能被以后维护的人员快速理解？
斟酌之后，断然抛弃了这种实现，因为，不能把所有的数据都放在后台。
就拿icon字段来说，如果我们采用了上述实现：
那当我们以后想修改前台菜单图标的时候，需要去修改后台的数据初始化。这显然不合理，以后维护的人员肯定会存在一个疑问，这是谁设计的菜单？我改个前台的图标为什么要动后台？
新设计既然不能讲数据都放在后台，那前后台就各司其职。
前台：包含菜单名称，菜单图标，菜单路由等信息。负责前台菜单的格式显示。
后台：只保留，菜单名，菜单路由，父菜单三项信息。负责后台用户的菜单授权。
核心思想就是：前台配置好所有的菜单，但默认将菜单隐藏。
应用启动时，查询后台接口，获取当前用户的所有授权菜单，授权一个，前台就显示一个。
前台菜单：写菜单时将hide置为true，默认隐藏。
menus: [
{
text: "主导航",
group: true,
children: [
{
text: "首页",
link: "/main",
hide: true,
icon: "anticon anticon-compass"
},
{
text: "系统设置",
link: "/setting",
hide: true,
icon: "anticon anticon-setting"
}
]
}
]
然后就是具体的逻辑，先获取前台的菜单，即所有菜单。
获取当前用户授权菜单列表，以路由表示该菜单唯一，如果路由被授权，就把hide置为false。
