原文地址：https://www.zhihu.com/question/20313385
作者：Vance
链接：https://www.zhihu.com/question/20313385/answer/118095995
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
后台产品狗，之前踩过权限控制系统的大坑。做完项目整体复盘，发现坑爹的不是难设计，而是对现有权限控制情况的了解程度低。如果在平台设计之初就考虑到权限控制的问题，是好事。越早进行系统的考虑，成本越低，效果也越好。最好的当然是之前有成熟的系统可以接入复用。如果没有的话，那就得尝试自己理解这一套东西，并深入了解现有情况再进行设计了。谈到权限控制的设计，需要先理清楚定义和原理。所以我们需要看到权限控制中，控制的本质，也就是说控制的是什么？其实是：用户与可以进行的行为的关联关系。这句话中有3个关键词：用户、行为、关联关系。衍生出如下几个问题关于用户用户是怎么分类的（用户角色）
用户和用户之间是否有关系？如果有，是什么关系？关系是什么结构的？如公司组织架构那种层级分明的树形结构关于行为怎么将行为分类（一般来说按照行为目的区分、按照行为业务类别区分、按照行为与系统的交互类型区分）例如，按照行为与系统的交互类型区分数据权限：指的是用户有权操作的那部分数据（读、写）功能权限：对使用人群在功能修改使用等方面权利的限制行为之间是否有层级和依赖关系，是怎么样的依赖关系关于关联关系是一对一还是一对多，如果有父子层级之分，是继承关系还是独立存在。这是概念层的问题，具体到工作的设计当中，用于梳理需求会有一些帮助，主要还是用于梳理基础概念。一句话概括就是：权限系统维护的是人和可进行行为的关联关系。那么系统的每个用户可以看做是一堆可以进行的行为的集合。这句话有点不好理解的话，你就按照用户画像那么理解，在权限系统里，每个用户身上打满了一堆可以进行行为的标签。
那么权限控制系统的原理呢？
其实很简单，就是：
用户在访问时，通过了解用户具有的可以进行的行为的集合，决定用户可以看到什么菜单，以及在什么菜单下能使用什么功能，并且具备什么样操作数据的能力。了解完概念，那么在动手之前，是了解清楚需求及目前的解决方案。
比如：
现在都有什么类型的用户？
每个类型的用户在使用功能上有什么区分？
现在一级菜单和二级菜单都有哪些？
每个页面上面通用的和需要控制的功能都有什么？
哪些数据的读写需要根据用户身份做区分？
PS：大部分没有权限控制之前，很多权限控制是写死在代码里了，需要梳理清楚，避免踩坑。好了，其实回答完以上问题，应该能了解自己或公司对权限系统的基本需求了，按照我的习惯，就可以着手开始写use case了。具体的情况，具体分析，最大的难点在于对现有情况的了解，了解清楚现有情况，其实设计难度不大。更多阅读：RBAC权限管理
作者：Vance
链接：https://www.zhihu.com/question/20313385/answer/118095995
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。