角色权限设计的 100 种解法以下作者结合自己的几次权限设计经历，提供一些所谓的经验套路，希望各位设计师从此微笑迎接权限需求。 一、令人头疼的权限设计 设计师在进行设计时，常常会抽象出对产品有诉求的多个角色，再依据角色的特性去梳理使用场景并设计。 当角色之间的使用场景不冲突，不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案。比如：网易云音乐同时为需要听歌和听电台的用户，提供所有的功能。 当这些角色的使用场景完全不重叠、流程对立时，我们会设计完全独立的两套系统，如滴滴的司机端和乘客端； 但除了以上两种情况，在大多数 B 端产品中，基于流程公正性、信息安全性等因素考虑，各个角色的使用场景是部分通用，部分隔离的，这时候就需要引入“权限系统”了。 设计师有时会对角色权限系统有一丝畏难情绪。一方面因为角色权限系统的配置作为一个非常后台的管理功能，在竞品调研过程中很难通过上帝视角去解剖其中逻辑，自己琢磨又较难透彻；另一方面对于角色权限系统，做好了并不能代表设计能力有多优秀，但一旦没做好就会导致整个流程不通、产品崩溃。所以设计师常对权限系统望而却步。 以下就笔者的几次权限设计经历，提供一些所谓的经验套路，希望各位设计师从此微笑迎接权限需求。二、基于技术模型进行设计-RBAC 模型 进行设计前，最好能够理解技术模型。在业界接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型，其基本理念是将“角色”这个概念给予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。以下就模型与设计相关的几点做一下简单介绍。1. 基本的 RBAC 模型 假如没有角色的概念，系统中每加入一个用户，就需要为这个用户配置一遍权限，下图是 wiki 中直接为用户权限管理方式，可以看出管理成本巨大。 而引入“角色”概念后，如下图即是 RBAC 模型中最基本的模型：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。 此时只需要为角色给予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。2. 引入用户组概念的 RBAC 模型 在大型平台的应用上，试想假如用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念。假如部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，...
