تسجيل الدخول الآن 说起权限设计，RBAC 几乎是个绕不开的起点。它的想法很朴素：不直接把权限塞给用户，而是在中间加一层“角色”，让角色去关联具体的资源权限，再把角色分配给用户。这样一来，授权和回收就灵活了不少——这其实也暗合了计算机世界里一个常见的思路，系统太复杂，加一层抽象往往就能化解很多麻烦。
可一旦落到日常的业务系统里，你就会发现，最基础的 RBAC（也就是 RBAC0）虽然好理解、好落地，却很难覆盖现实中的组织关系。尤其是用人制度上，大多数企业遵循的是“以岗定人”，而不是把人直接挂在权限上。当有人调动、兼职或者岗位职责调整时，理想的情况是，只要更新了组织关系，对应的权限就能自动跟着变，不需要管理员一个用户一个用户地去改。这样既减少了工作量，也更贴近实际的人事操作。
那么问题就变成了：怎么把组织架构、岗位和权限模型合理地揉到一起去？这就要先看清组织结构有哪些绕不开的特点，再给出一个可落地的模型。
企业的组织结构通常是树状的，一层一层往下铺。同一层级里会有不同的职位，不同职位间的权限天然不同——比如财务部里的会计和出纳，能看的数据、能做的操作肯定不一样。但不同职位之间又常有重叠，像办公室主任，除了拥有普通员工的权限，还会多出一些审批和管理的职能。更常见、也更容易被忽略的是，同一个职位下面往往不止一个人，而且一个人可以同时担任多个职位。比如“副总经理”这个职位，可能同时坐着赵云和赵德彪两个人；而赵云除了担任副总经理，还兼任着总会计组织的负责人。这种“同岗多人”和“一人多岗”的现实，如果权限模型没处理好，维护起来就会非常痛苦。
把这些特点吃透之后，再设计模型，思路就清晰多了。在谈具体方案之前，先统一几个关键名词的含义，免得搅在一起说不清：
- 账号：就代表一个真实的人，是登录系统的入口。
- 资源：系统里的菜单、页面、数据等等，凡是需要控制访问的东西。
- 角色：一组资源操作权限的集合，比如“查看报表”“编辑客户信息”这些操作权限。
- 职位：同一类岗位的统称，比如“副总经理”“出纳”，它是一个职位类别，不直接对应具体的人。
- 岗位：组织里具体到人的一个坑位，一个岗位只能对应一个人，但一个人可以同时兼任多个岗位。
直接给账号挂资源肯定不行，颗粒度太细，后期维护成本高得没法接受。更合理的做法，是把角色和职位绑定，让同一个职位类型下的所有岗位共享同一套角色。这样一来，权限的调整只需改动职位的角色配置，就能同步影响到所有坐在这个职位上的人。
接着上面的例子，假设“副总经理”这个职位绑定了四个角色，每个角色控制不同的资源。赵德彪只担任副总经理这一个岗位，当他登录系统时，系统会识别出他所在的岗位C，岗位C对应的职位就是“副总经理”，进而查出这个职位绑定的四个角色，赵德彪便拥有了这四个角色权限的总和。
赵云的账号要复杂一些。他同时担任副总经理和总会计组织负责人两个岗位。系统会分别查出这两个岗位各自对应的职位，再找到每个职位绑定的所有角色，最后把权限合并在一起。这样他登录后，除了拥有副总经理的权限，还叠加了总会计负责人那个职位的资源访问能力。整个过程对用户是透明的，管理员只需要在组织关系里维护好岗位和人员的对应关系，剩下的权限计算全部由系统自动完成。
整体来看，这个模型其实就是把 RBAC 的角色层跟组织结构做了一次衔接：账号—岗位—职位—角色—资源。岗位成了连接人和职位类别的枢纽，职位又成了连接组织与权限的桥梁。这样一来，无论是调岗、兼职还是部门合并，只要动组织关系那一层，权限就会跟着平滑变化，不用再跑到角色分配里一个个去改。
当然，这个模型也不是万能的，实际落地时还会遇到一些细节，比如临时项目组、跨部门协作等，还需要更灵活的策略。但至少，它解决了一个非常普遍的问题：当一个人占着好几个坑的时候，权限该怎么给才不会乱。希望这个思路能给你一些启发，也欢迎一起交流。