3. RBAC 核心规范：核心RBAC、层级RBAC、约束RBAC
RBAC 这玩意儿，很多人都听过，但真正理解它三个层次的，其实不多。
当年我刚接触权限设计，以为就是用户→角色→权限，很简单。后来在银行项目里摔了几次跟头，才知道里面的门道。今天我把这三个规范掰开揉碎，咱们一起看看。
3.1 核心RBAC：最小完备集
核心RBAC，说白了就是最基础的那一套。它定义了五个基本元素：用户、角色、权限、会话，以及两个分配关系：用户-角色分配、角色-权限分配。
规范很简单：
- 一个用户可以有多个角色。
- 一个角色拥有多个权限。
- 用户登录后创建会话，会话里只激活该用户的一部分角色。
核心RBAC的本质就是三个字：用户-角色-权限的映射。没有它，后面两层全白搭。
我当年在做一个OA系统时，就只用了核心RBAC。用户分“员工”“经理”“总监”，每个角色配一套菜单权限。项目上线三个月都没出问题。但后来需求一复杂，就顶不住了——总监和经理之间的权限有大量重复，每次改权限得改两个角色，累死人。
这让我意识到，光有核心RBAC是不够的，还得引入角色继承。
3.2 层级RBAC：角色继承
层级RBAC就是在核心RBAC上加了角色之间的上下级关系。子角色可以继承父角色的所有权限。比如“经理”继承“员工”的权限，再额外加几个管理菜单。
这里的玩法有两种：
- 完全继承：子角色拥有父角色的全部权限，再加自己的。这是最常见的。
- 受限继承：子角色只能继承父角色的一部分权限，需要手动选择。这种很少用，但在某些金融系统里出现过。
注意！角色继承最怕两个坑：
- 循环继承：A继承B，B继承C，C又继承A。这会导致无限递归，系统直接崩掉。
- 菱形继承：C同时继承A和B，而A和B又都继承自同一个父角色。权限会重复，必须去重。
我在某个电商项目里用过三级角色继承：普通用户→运营→运营主管。一开始很爽，但后来角色越建越多，权限像雪球一样滚，一个主管角色下面挂了几百个权限。到最后，谁都不敢删任何权限——怕影响别人。这种“权限膨胀”问题，就得靠约束RBAC来收口。
3.3 约束RBAC：安全边界
约束RBAC，我个人觉得是这三个规范里最考验架构功力的。它给角色和用户加了各种“紧箍咒”，防止越权操作。
约束分三类：
| 约束类型 | 说明 | 真实案例 |
|---|---|---|
| 互斥角色 | 同一个用户不能同时拥有两个互斥的角色，或者一个会话里不能同时激活两个互斥角色。 | 出纳和会计不能是同一个人，否则你做我审全是自己说了算。 |
| 基数约束 | 限制一个角色最多能给多少用户，或者一个用户最多能拥有几个角色。 | “超级管理员”只能分配给3个人，防止权限滥发。 |
| 先决条件角色 | 激活某个角色之前，必须先激活另一个角色。 | 想激活“高级审批”角色，必须先有“普通审批”角色。 |
我在某银行项目中，把“经办、复核、授权”三个角色设成互斥。单笔交易必须由不同的人完成经办、复核、授权。这个约束救过我一次——有一回测试账号不小心被人用了，但因为互斥约束，他一个人做不了全部操作，保住了生产数据。
你想想看，如果没有约束RBAC，核心RBAC和层级RBAC就像没装护栏的高速路。车再好，也容易翻出去。
三种规范的关系
它们不是并列关系，而是层层叠加的：
- 核心RBAC是地基——用户、角色、权限、会话。
- 层级RBAC是第一层——角色继承。
- 约束RBAC是最上层——互斥、基数、先决条件。
实际项目中，绝大多数场景只需要“核心RBAC + 约束RBAC”就够了。层级RBAC虽然好用，但容易把权限模型搞得太复杂。我现在的习惯是：能用平级角色解决的，绝不搞继承。只有当角色数量超过20个，且存在明显的上下级关系时，才考虑引入层级。
千万别为了炫技而用层级RBAC。我见过有团队给50个角色做了五层继承，最后想加一个新权限，得从最底层一路查到最顶层，所有人都想哭。
下面这张图把三个规范的关系画清楚了：
三种规范各有各的用武之地。核心RBAC好比“人、岗位、门禁卡”的映射；层级RBAC是“部门副职自动拥有正职的部分权限”；约束RBAC则是“财务和审计不能是一个人”。
最后说句实在的：不要一上来就想实现全部三层。从核心RBAC起步，遇到痛点再逐层加。我见过最稳的权限系统，就是核心+约束两层，层级只用了一点点继承。够用，不乱，好维护。