用户、角色、权限这三个要素几乎是所有系统的必须考虑的基础功能，也可以说是支撑整个系统的底层功能。现在讨论的是，如果搭建适合的权限系统。

就目前所知，几乎每个公司都有专属自己的底层权限分配系统，适配自己的产品，但是有一个很基层的东西，一般在设计的时候都会被遗忘：all or one 的问题。

all - 通俗来说，就是系统管理员，在权限系统的设计里，他就是大 boss，拥有整个系统所有所有的权限。

one - 就是简单的我们，岗位属性决定了你这个角色拥有的权限。

相信在很多的设计过程中，并没有考虑清楚每个角色能做什么，要做什么，导致的最终结果就是，我和老板说，不行啊，我想要看那个东西，给我开个管理员权限吧……诸如此类的，久而久之，系统里几乎人人都是管理员，那么角色这个概念就没有了。

当然也有很大一部分原因是，在设计这个权限系统时，对相关的设计作了较为复杂的固定模式，一般来说，就是通过代码直接写死这个权限或者用户名。这样，在后期的维护中，我们就无法获知整个系统里的真正用户属性及其权限控制情况了。

感觉好像有点扯远了，还是简单说说我对这三个概念的理解吧。

用户，就是我们的ID，识别我们的身份；角色，相对来说就是我们的属性，在一些内部系统中，用更清晰的岗位职责进行划分；权限，其实就是很简单的告诉你，你可以看到哪些内容以及可以做哪些操作。

很多人认为，只要把权限分清分细了，就可以解决上述提到的一些问题了。当然，我以前也这么认为，但是，当最近在整理权限系统结构的时候，我发现了一个无解的问题，权限已经是分到很细很细了，然而，我的角色却被模糊了，在大方向上的职责是没有问题的，但是，当你多个角色的时候，就很容易相互影响，甚至，由于在初期设计时，为了方便而设计的系统管理员的概念导致了我的权限组逐渐被模糊化了。

由于我还是新手，所谓的解决方案不一定适合所有，因此，最后的这部分，我并不想提出任何的方法，只是简单的把我目前思考到的东西写下来，至于正确与否，见仁见智吧。

第一：权限来自何处

在设计的初期，我们应该思考的第一个问题，就是我们的权限是怎么赋予的。

由于权限是整个系统的最底层基础，他的颗粒度决定了后续对权限分配的法则。在这里必须要提一下的是，权限的颗粒度要尽可能的小，真的，必须要小到可以实现随意分配的原则。

第二：我有什么权限

这应该就是每个人都会提出来的问题，在初始接触到系统的时候，你一定会十分十分的好奇。这个时候，我们思考的是，你是谁，你负责什么，换言之，就是你的岗位职责是什么。根据岗位职责的内容定义角色，这就是初始角色的概念。我给了你这个角色，你用这个角色进行操作，那么你就只能做这些事情。

第三：用户的账号

有很多系统同时存在两个概念，一个是账号，一个是账户。刚接触到的人，一般都会蒙圈，什么是账号，什么是账户，两者不是一样的吗？当然是不一样的！特别是现在较为敏感的互联网金融圈，对这两个之间的区分是很严格的。账号，一般来说是你的登录用户名，简单点，就是你的身份证；账户，就是对应在不同的圈子里你的不同身份属性。看到这里，可能会感觉到账户和我之前提到的角色很类似，在部分系统中，账户就等于角色。

账号，其实就是我们的登录号码，同一个账号如何划定我的工作圈子，这就是当前的账号的概念。

一般来说，只要处理好三者之间的关系，基本就能搭建好比较基础的权限系统，但是，我们还忽略了一个产品的概念！一个系统，一个公司，不可能只有一个产品，他可以有多个多个产品，我可能是A产品的这个角色，也可能是B产品的另一个角色，也有可能是我还拥有所有产品的所有角色。这个时候就开始尴尬了，要控制好每个角色和产品间的关系，也是很重要的。当然这个还是有办法实现的，不过靠的就是对这些基础的控制了。

这些东西真的很基础很基础，我写下来也不是说要指导什么，只是把一个想法告诉大家，不要以为角色权限的内容不重要，到最后，往往导致系统崩溃的可能就是当初对权限的控制没有把握好。

例如，在对系统进行重构的时候，相信开始设计的权限系统已经能把所有的控制都做好了，因此很多人都会直接套用了底层的权限管理模块，然而，忽略了一个问题，新系统里有没有增加新的元素，如最简单的产品！因此，在这个分配的时候就开始尴尬了，因为产品要和角色挂钩就需要重新考虑权限系统的设计，增加一个新的控制节点，在后期编写系统功能的时候，存在很多的权限问题，特别是产品间的保密，这就更加要求严格控制所有的权限。尤其是，我们不能任意系统管理员！

好了，暂时想到这些，有其他的再补充吧~~

无图，懒~