2023年后台权限管理设计思路：三种模型分析

后台权限管理设计思路：三种模型分析01超简版本-用户/权限模型

用户直接与权限映射，这种设计的优势在于简洁直观，适合用户数量不多，功能较为简洁的系统，它的劣势也是特别的明显当用户量增多时，维护成本较高，可扩展性差。

系统页面Demo：

02

进阶版本-用户/角色/权限模型

若系统用户和功能增多，为每一个用户匹配单独的权限，会变得特别的繁琐，因此权限分门别类，形成“权限包”。从用户的角度，将用户分类，同一类用户固定为相同的角色，给予相同的权限，会让操作变得简洁许多。

系统页面Demo：

03

层级版本-组织/用户/角色/权限模型

对于管理性后台，往往人员是职级区分的，比如用户王五为销售组长，其组员赵六和孙七，王五需要看到赵六和孙七的销售额数据和可以进行赵六和孙七的全部操作，而赵六仅能看到自己的销售额数据，进行和自己相关的操作。

这个事例中引入了两个新的概念，一是用户的权限可以细分为功能权限和数据范围权限，二是数据范围和功能权限都有了继承的层级概念。

所谓功能权限大家比较好理解，比如能否看到某个页面，能否点击某个按钮。而数据权限略抽象些，比如在业绩报表模块，从功能权限角度，可以打算用户能否打开这个报表页面，但是不同用户进来看到不同的数据（王五需要看到赵六和孙七的销售额数据，而赵六仅能看到自己的销售额数据，看不到孙七的），则是由数据范围来掌握的。

1.数据范围的继承

我们可以将用户进行分级管理，比如建立多层级的组织架构树，将不同用户放置于组织架构的不同根节点上，来实现多层级用户的建立和管理。

1）假如用户的层级假如比较简洁（不多于三级），可以将层级关系融入到角色之中。比如用户分为三级：管理员-组长-组员，管理员能看到全部的数据范围和拥有全部的功能权限，而组长能查看组员的数据范围和拥有部分功能权限（比如无法编辑用户），而组员的数据范围仅仅为自己负责的数据和拥有部分功能权限。

我们可以在组长这个角色下，允许其绑定组员，针对不同的角色设置不同的数据范围读取方式，管理员可以读取全部数据范围，组长需要读取其组员的，组员只能读取自己的。大家有爱好可以去了解下RBAC0/1模型

2）而对于用户层级较多的状况，建议采纳多层级的组织架构的管理模式，先建立公司的组织部门，再将人置于组织架构树的不同节点之下。以用户在组织节点的位置，以及是否为某个节点组织的负责人，来确定其数据范围。

2.功能权限的继承

一般是将角色进行分级，有了所谓的角色树的概念

由此，我们就得到了自由度更高但是规律更简单的权限管理

涉及到组织架构树和角色树，需要考虑到的场景更多，这些细节要依据实际的业务场景来制定方案。比如：

组织有成立和解散的时间，员工也存在转岗换组织部门的状况，因此要考虑引入时间轴的概念。增加许多的校验规律，比如需要增加员工入职、离职时间，且员工在该部门任职的时间不能早于部门成立的时间等等同一员工能否兼岗，允许在多个组织下存在角色上是否会有互斥状况存在（RBAC-2模型），比照实际业务中，发钞和验钞的工作不允许同一个人做，因此在功能设计时要考虑角色之间的互斥性，通过为用户配置角色来实现用户与权限的映射关系，不同权限间是存在优先级的，比如刚刚的例子，互斥关系为最高优先级实体关系图：

系统页面Demo：

上述分析的三种权限管理其实并无优劣之分。权限管理作为系统的基石，应依据系统目标用户特点、后续进展方向、维护成本等方面进行综合评估，找到最适合系统的模式即可。

学问点总结

用户管理核心是解决用户与权限的问题；角色可理解为一类用户，或者一堆权限的集合，链接了用户与权限的关系；权限可以分为功