因为每个项目都有管理后台系统角色权限管理设计，90%都会有权限管理。 在我自己的历史项目中，我一直对权限有比较肤浅的认识。 直到去年学习了钉钉的管理系统，今年对产品进行了重构，我才对权限有了深刻的认识。
1. 有哪些权限？
我对权限的理解是，一开始是一个管理后台某些模块的账号； 这时候的权限就很简单了。 这是一个帐户列表。 您可以编辑账户信息并设置账户查看菜单，即账户yimi可以管理订单列表。 。
后来接手了一些门店端项目系统角色权限管理设计，在差异化菜单查看中也加入了数据差异化，即账户yimi可以管理**门店的订单列表数据； 我认为以上两项基本上可以支持中小型项目。 足够使用。
然后再更深层次来说，当你接手一个大型项目时，你的后端管理员来自一个团体，或者数百人。 这时候，一个账号的区分是远远不够的； 它还扩展到开发 CRM 系统。 当我研究钉钉的逻辑时，权限不仅仅是开个账号那么简单（只有账号+密码），而是权限是针对不同部门的人的管理。 那么这个时候账号和菜单权限就会分离。
账户是一个部门的成员，可以通过手机号码唯一标识。 菜单权限根据不同角色划分。 财务有哪些菜单，采购有哪些菜单？
听到这里，涉及到权限：部门、成员、角色、菜单。 那我就会觉得权限可以复杂也可以简单，但其实只是人在管理东西而已。 那么不同的权限设计有什么区别呢？
2. 最小权限设计
最小权限设计，如下图，有登录账号、密码、菜单查看。 其实还有XS版本，只有账户，没有菜单权限分离。
那么什么情况下会采用这种最小权限设计呢？ 我个人的理解是项目小，或者客户内部运营架构比较简单； 此时有几点需要注意。 第一个拥有整个菜单意味着拥有该菜单的所有操作。 第二点是没有数据隔离，即每个具有菜单权限的管理员查看的内容都是相同的。
要求总结如下：
3、中型项目的权限设计
对于中型项目，类似多个门店，或者负责角色不同，同一个模块需要查看不同的数据，执行不同的操作。 如下所示：
中型项目权限设计-编辑管理员-图2
中型项目的权限设计-编辑角色-图3
相对于最小权限设计，你可以理解为菜单+账户的拆分，在菜单的基础上游戏开发素材，扩展了操作权限； 通过角色的区分，也扩大了数据权限。 此时的权限=菜单权限+操作权限+数据权限。
与前一种相比，要复杂得多。 为什么前面说建议按照产品体系来搭建这个中等规模的权限体系呢？
一方面，众所周知程序开发，由于开发工作量和难度，相应的报价会很高； 另一方面，其复杂性也增加了其使用难度。 如果没有这样的业务情况（类似多个门店，或者负责不同的角色），不建议使用。
最后也是最重要的一个方面，关于不可持续产品的说明：不断向软件添加功能是不可持续的。 日益复杂意味着遗留代码越来越重，导致产品维护成本越来越高，灵活应对市场变化也越来越困难； 我认为这个原则不仅适用于用户前端，也适用于管理后端。
相应的要求总结如下：
4、大型项目的权限设计
大型项目权限最大的变化就是有了部门组织架构，不同部门的人使用系统，即管理员管理被分解为部门管理+成员管理，但不仅仅如此。
在权限审批系统或者CRM中，数据往往是相对独立的，可以按照部门组织结构来区分数据权限。 如下所示：
大型项目权威设计-部门组织架构-图4
如果说中型项目的数据权限按照门店或者地区来划分，那么部门树就是数据权限的另一个维度。 根据创建者所在的部门，该数据归属于某个会员或部门（这里还需要考虑会员拥有多个部门的情况）。 同一个部门的数据是独立的，主管可以查看每个人的数据。
那么这种数据划分并不适用于后端管理的所有列表。 比如用户列表、订单列表等数据源不是来自后端，或者是一些文案管理的列表。 无需区分数据； 因此，在开发时，还需要在每个列表中列出指令，是否使用； 这个逻辑实现确实比较复杂，整个权限系统可以相当于一个小项目。 我大致写出了这个需求的功能点，有需要的朋友可以再问我。
5. 总结
权限仍然是一个系统模块，可简单可复杂，但仍然需要根据需求进行设计。
只有熟悉了产品体系和需求后，提出的解决方案才更具有针对性和说服力，才能真正解决问题。 所以，也建议大家如果对权限系统感兴趣的话，有时间可以在钉钉和飞书上多研究一下。 虽然软件不能完全复用，但大厂的解决方案、每个模块甚至每个文案内容，都凝聚着整个技术团队的心血，还是值得学习的。
文章来源:https://blog.csdn.net/qq_41661800/article/details/122606318
