对于 B 端的 PM 来说，权限设计可以说是最基础的技能之一了，对于权限设计的相关问题，行业内也都有很多比较成熟的解决方案，RBAC 模式甚至都演变出 RBAC1、RBAC2、RBAC3了，这对于很多人来说反而加大了理解的难度。今天我就从另一个角度来跟大家探讨一下权限设计的看法。

权限来源于用户管理的需要，而最终又作用于用户。对于 B 端产品来说，通常都会包含很多不同的功能模块，有针对运营人员的模块、财务人员的模块或者管理人员的模块，在实际的使用场景中，由于用户职责的不同以及企业对员工接触数据的限制等，需要 B 端产品能够支持不同用户登录同一应用去使用相应的模块，彼此互不干扰，因此便有了权限设计的需求。

沉下心来仔细想想系统权限的构成，其实无非就是功能权限（页面和操作）和数据权限，我们平时在设计权限的时候，其实要做的就是控制用户哪些页面能进入、哪些操作能做，哪些数据能看到。

在互联网行业，权限模型有很多种，比如 DAC、ACL、MAC、RBAC、RBAC1、RBAC2、RBAC3 等，在这里我主要讲 RBAC，因为 RBAC 是目前 B 端产品最受用的权限模型，没有之一。

RBAC，即 Role-based Access Control，字面意思就是基于角色的权限控制，实际含义即字面上说的，通过给用户赋予角色来控制用户的权限范围。比如小王和小张都是销售人员，那么可以定义一个销售人员的角色，给销售人员这个角色赋予权限，然后在系统中将小王和小张设置为销售人员，那么小王和小张就都具有了销售人员的权限。

上文中，我提到了权限的意义、权限的构成以及最典型的 RBAC 权限模型，目的其实是想跟大家传达一点：权限设计的目的无非就是控制用户哪些页面能进入、哪些操作能进行、能看到哪些数据。当产品能清晰了解权限设计的目的，再复杂的权限场景都不在话下。

本人之前在做权限设计的时候有遇到过一些坑，在此也跟大家分享一下，避免还有人也踩到一样的坑：

∙ 注意页面地址的权限控制：通过菜单控制权限是比较常见的做法，如果没有加路由权限，那菜单地址被暴露后，其他人员就可能通过直接访问页面地址的方式进入到相应的页面内；

∙ 注意接口权限的控制：这一点应该比较少见，因为开发人员在开发接口的时候通常都会加上各种鉴权方式；

∙ 注意权限复杂度的控制：在设计权限的时候，不仅仅要考虑到完美控制好用户的权限范围，还要考虑到权限模型的易用性，否则对用户来说是非常灾难性的事件。

权限设计虽说只是非常基础的模块，但可谓是牵一发而动全身，也是很关键的设计要点，产品经理在这里是万万不可疏忽的。以上是我对权限设计的一些看法，大家有其他想法欢迎留言探讨。