编辑导语：权限管理是所有后台系统的都会涉及的一个重要组成部分，在管理后台中对于权限的标准需要准确地把握，并且根据各种需求进行设计，达到最终目的；本文作者分享了关于权限系统的设计，我们一起来了解一下。
写在前面，为什么要写权限系统的设计呢？
因为每一个项目，有管理后台，90%会有权限管理。在我自己历史以往的项目，其实对于权限始终是一个相对表面的认知。直到我去年研究了钉钉的管理系统、以及今年做了产品重构，让我对权限有了一个深度的认知。
一、权限是什么我对于权限的理解，一开始是一个账号，管理着后台的某些模块；这个时候，权限很简单，他是一个账号列表，可以编辑账号信息以及设置账号查看菜单，即账号yimi可以管理订单列表。
后面接了一些门店端的项目，在区分菜单查看上，也加上了数据区分，即账号yimi可以管理**门店的订单列表数据；上面这两项，我觉得可以基本可以支持中小型的项目是足够使用的。
然后更深一个层级的，当你接了一个大型的项目，你的后台管理员是一个集团的人，或者是上百人，这个时候一个账号区分是远远不能满足的；也延伸了在做CRM系统的时候研究了钉钉的逻辑，权限不仅仅是开通一个账号（仅有账号 密码）这么简单，权限是对于不同部门的人的管理。那么这个时候会将账号跟菜单权限独立开来。
账号即部门下面的某个成员，可通过手机号作为唯一标识。菜单权限按照不同角色去区分，财务有拥有什么菜单、采购拥有哪几个菜单。
听到这里，权限就涉及了：部门、成员、角色、菜单。那我会觉得，权限可复杂可简化，其实无非是人管事。那么不同的权限设计会有什么区别呢？
二、最小权限设计最小的权限设计，如下图所示，有登录账号、密码、以及菜单勾选。其实还有个XS版本的，即仅有账号，无菜单权限分隔。
最小权限设计-图示1
那什么情况会使用这种最小的权限设计，我个人的理解是小型的项目，或者说客户内部运营结构相对简单；这个时候需要注意几点，第一个拥有整个菜单即拥有菜单所有操作，第二点是没有数据隔离，即每个拥有菜单权限的管理员查看内容一致。
对于需求梳理如下所示：
中型大小的项目，类似于多门店、或者是负责角色不同，同个模块需要查看不同数据、进行不同的操作。如下图所示：
