编辑导语：任何系统/产品搭建时，最先考虑的都应该是权限管理模块，而且权限管理模块的清晰、稳定是平台产品健康发展的基石，权限管理核心考虑的问题是用户与权限的关系。本文作者对三种不同权限管理的版本展开了梳理分析，与大家分享。

01 超简版本-用户/权限模型

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

系统页面Demo：

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

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

系统页面Demo：

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

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

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

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

1. 数据范围的继承

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

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

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

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

2. 功能权限的继承

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

由此，我们就得到了自由度更高但是逻辑更复杂的权限管理

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

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

实体关系图 ：

系统页面Demo：

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

知识点总结

1. 用户管理核心是解决用户与权限的问题；
2. 角色可理解为一类用户，或者一堆权限的集合，链接了用户与权限的关系；
3. 权限可以分为功能权限和数据范围；
4. 复杂的继承关系，数据范围依赖用户组织架构树，功能权限依赖角色树，将用户放置于组织架构树的不同节点上，并赋予角色，即解决了功能权限和数据范围的问题；

作者：yingying之语；公众号“yingying之语”，持续分享B端产品设计经验，期待与小伙伴们一起交流探讨

本文由 @yingying之语 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议