设计及原理

操作者的身份，不同身份权限不同，看到的菜单内容也不同。常见的角色有：运营、开发者、admin 等。

即用户在系统中可以看到的页面,菜单为树形结构，包含多个一级菜单，一个一级菜单包含多个二级菜单或页面，二级菜单包含多个页面。

菜单信息一般包含

当用户拥有某个菜单，那么该用户便拥有菜单下的全部请求路径，比如增删改查，但是需求是该用户拥有菜单下的查，但是没有增删改权限，所以不能将菜单和权限直接绑定。

我们的实现方案是菜单就是菜单，数据权限就是数据权限，因为有些接口不属于菜单，它可能是页面上的一个按钮，可能是所有人都拥有的权限，

像这种所有人都有的权限，它只需要校验你有没有带 token，而不需要你拥有某个角色才能访问，为了方便管理这些权限，我们对这些权限进行了分组，

例如基础权限（根据 token 获取个人用户信息，获取个人菜单树，查询个人消息、、、），其他权限。

权限管理系统的核心是管理角色的权限。即角色、菜单、权限之间的关系。上面讲了各个组成后，这之间的关系就比较简单了

角色配置的时候和菜单、接口进行绑定，所以就实现了角色-菜单-接口权限之间的对应关系。

标准的 RBAC 有 5 张表，分别是 user, role, menu, user_role, role_menu

但是为了方便也可以去掉关联表，留下了 user, role, menu, 但是它们之间的关系任然存在，即 RBAC 模型任然存在，这样可以提高查询效率，

权限系统的前提

使用权限管理系统需要有两个前提

拥有账号体系意味着能够获取用户 id，此时权限管理系统才能被使用。

很多公司做权限管理系统的时候，并没有申请流程。添加新用户需管理员在后台人工添加，不但需要录入大量信息，而且容易出错，大大增加了管理员的成本。

合理的方式为，用户申请权限，系统自动录入数据，管理员审核

权限管理系统往往用于后台，虽流量不高，但也需要关注性能问题，尤其像接口权限验证，几乎每次都需要请求，此时就需要使用缓存来提高性能。

按照该设计搭建的权限管理系统可以满足大部分业务需求。角色和菜单、接口进行绑定，这种设计更直观、易理解。