作者|小菜
Hello，大家好，今天给大家讲讲用户权限。可能有人会觉得用户权限有什么好讲的，市面上通用的RBAC权限模型多了去了，还需要你个小菜鸟来讲。说这话的，可能没看到我背上纹的小猪佩奇，信不信我这个社会人给你来点狠的——求着你看完。咳咳…严肃严肃，相信我，看完你会有收获的，没有收获的来砍我，千万不要砍需求。
一、什么是权限
不管是B端产品还是C端产品，权限基本都会出现。常见的比如说知乎、简书等内容类产品，你只有登录才能评论、点赞，不登录你只能浏览；再比如知识付费或视频类产品中，你只有付费了才能完整查看专栏里的内容，不付费你只能试看几分钟；再复杂一点的，就是企业级产品中，各部门，各岗位，不同用户能操作的权限都不尽相同。
百度百科中对权限的解释是：“为了保证职责的有效履行，任职者必须具备的，对某事项进行决策的范围和程度”。有点拗口，用我的话来理解就是“能不能干”。想污了的同学请遵守交通规则，系好安全带，谨防疲劳驾驶。
权限按类型划分为三类：页面权限、操作权限和数据权限。页面权限很好理解就是能不能进这个页面；操作权限就是对于这个页面中的增删改查按钮以及其他按钮能不能操作；至于数据权限，就是不同用户进来看到的数据不一样，比如说研发部门只能看到研发部的数据，产品部只能看到产品部的数据。
用户权限实际上是控制用户可用的功能点。换句话说，权限的最小单元是功能点。如果把一个产品或者系统比作一幢房子，那功能点就是房子里的一个个上了锁的房间，用户只有拿到相应的钥匙才可以使用产品。
了解以上信息后，我们开始以产品化的思维去设计这个产品，根据MVP原理先推出个用户权限1.0版本。
二、用户权限V1.0
最简单的用户权限，就是把用户和功能点直接关联起来。
通过这种方式我们可以很灵活的控制用户权限。用户想要什么权限，我们就把对应的功能点分配给用户，用户拿着对应的钥匙就可以打开一个个房间。
这种权限模型在实际应用场景中，往往适合功能点较少的产品，比如说只有登录限制、付费限制等。如果一个产品的功能点过多，那么这种模型就会给用户带来非常繁琐的操作。
想象这样一个场景，假设你的一幢5层楼酒店有50间上了锁的房间，每一层都是不同的×××员负责房间卫生。你每次都要从一堆钥匙中找到对应楼层房间的钥匙，交给对应楼层的×××员，光是找找就非常麻烦了。如果房间再多一些，你的操作就会被几何倍数放大，到时候你就会崩溃了。
难道就没有更聪明的方法了吗？
自然是有的，基于这个需求我们对原有的权限模型进行迭代。
三、用户权限V2.0
作为酒店负责人，我可以把一楼所有房间钥匙串在一起，交给一楼的×××员；二楼的串在一起，交给二楼的×××员；后面的依次类推，这样我就不需要每次那么费劲地从一堆钥匙里去找了。
我们把一些功能点的集合叫做角色，再把相应的角色分配给用户，从而让用户拥有相应的功能权限。这种模型就是市面上常见的RBAC权限模型。
这种权限模型在实际应用场景中，适合功能点较多但用户规模不大的产品。功能点较少，用V1.0版本的更方便更灵活，那为什么说适合用户规模不大呢？
再来想象一个场景，还是那个酒店，现在每层×××员投诉你压榨他们劳动力，工作七天，全年无休，太累了。为了平息众怒，你决定每层都由10个×××员来负责房间卫生，这样一来你就要分配50次钥匙串。如果每层20个呢，50个呢，100个呢，你马上又会吐槽了，TMD破产品，把这个产品经理给我拖出去祭天。
别急别急，马上迭代。
四、用户权限V3.0
为了减少你的工作量，你决定把1楼的所有钥匙串都放在1楼×××员工作室，2楼的放在2楼×××员工作室…依次类推（当然每个楼层的×××员只能进本楼层的工作室）。这样只要是某个楼层工作室的×××员，都可以快速拿到负责区域的钥匙串，而不再需要你耗费精力去分配了。
我们把拥有相同权限的用户进行组合，叫做用户组，之后只要对用户组分配角色就好了，这样一来，只要是这个用户组下的用户就具备了相同的权限，减少用户繁琐的配置过程。
这种权限模型适合功能点比较多、用户规模比较大，而且产品单一的情况。为什么要强调产品比较单一呢？
好我们再来想象一下…为什么我要想，再想宝宝就要有脾气了，我刀呢。
OKOKOK，Anyway，我讲一个真实的案例。
去年我接手过一个湖北某市的项目，整个项目包含20多个教育类应用，给整个城市下的1000多所学校上百万学生、教师、家长使用。实施同学在配权限的时候直接崩溃了，每所学校20多个应用都要配对应的角色，而每次配的角色还是一模一样。你可以算一算，大概要操作多少次，反正我的手指头是不够用的。
同学同学，不要激动不要激动，马上迭代，现在可以把刀拿走了吗！
五、用户权限V4.0
我们把不同产品下的角色进行组合，叫做角色组，通过把角色组赋予用户组，达到快速配置权限的目的。
这种权限模型适合用户规模较大，产品线众多，功能点较多的情况。放心放心，我就不再继续假设，再假设下去估计刀就砍下来了。
六、总结
分析了那么多，其实大家可以发现，永远不存在通用的权限模型，只有最合适的，做产品也一样，不基于用户需求出发，随意套用公式模板，带来的危害是难以想象的。
细心的同学应该会发现，哪怕多么复杂的场景，用户权限V1.0版本都可以解决，无非用户需要多操作罢了。但是我们做产品的，永远是把复杂的留给自己，简单的留给用户，所以请相信数澜，这一直都是我们的最低产出标准。
最后，再想象一个场景，实际应用中，同一个部门（用户组）不同人员权限是不一样的，比如说产品总监和普通产品经理的权限就会不一样，怎么解决？