3、RBAC模型深度解析：RBAC0、RBAC1、RBAC2、RBAC3的核心概念与关系
聊到权限模型，RBAC 是绕不开的基石。很多刚入行的同学觉得 RBAC 就是「用户-角色-权限」三板斧，其实没那么简单。我在早期做数据平台权限设计时，就吃过「以为懂了 RBAC」的亏——后来才发现，RBAC 本身是一个家族，有四个兄弟：RBAC0、RBAC1、RBAC2、RBAC3。
今天咱们就把这四个模型掰开揉碎，看看它们各自长什么样，又是什么关系。
3.1 核心概念回顾：用户、角色、权限
在深入模型之前，先统一一下口径。RBAC 的核心三要素是：
- 用户（User）：系统的操作主体，可以是人、服务账号或机器人。
- 角色（Role）：权限的集合，是用户与权限之间的桥梁。
- 权限（Permission）：对某个资源执行某个操作的许可，比如「读取订单表」。
说白了，角色就是「打包好的权限包」。你给用户分配一个角色，就等于把一堆权限一次性给了他。这个思路，我在做第一个权限系统时觉得特别自然——谁愿意一个一个给用户勾权限呢？
核心原则：用户不直接关联权限，用户只关联角色，角色关联权限。这是 RBAC 的灵魂。
3.2 RBAC0：基础模型，一切从这里开始
RBAC0 是 RBAC 家族的老大，也是最基础的模型。它定义了最核心的关系：用户 ↔ 角色 ↔ 权限。
在 RBAC0 中，一个用户可以拥有多个角色，一个角色也可以被多个用户拥有。角色和权限之间是多对多的关系。嗯，这里要注意：RBAC0 没有角色继承，没有职责分离，就是最纯粹的「用户-角色-权限」三角关系。
我记得第一次给一个内部工具做权限设计时，用的就是 RBAC0。当时觉得够用了——几十个用户，三四个角色，简单明了。但后来用户量涨到几百，角色涨到十几个，就开始乱了。
适用场景：小型系统、用户量少、角色数量可控、权限关系简单的场景。比如内部管理后台、小团队协作工具。
3.3 RBAC1：引入角色继承，层级管理更高效
RBAC1 在 RBAC0 的基础上，加了一个关键能力：角色继承（Role Hierarchy）。
什么叫角色继承？简单说，就是角色之间可以有上下级关系。比如「高级管理员」继承「普通管理员」的所有权限，然后再加上一些额外权限。这样一来，你不需要为每个角色重新定义一遍基础权限。
我在一个数据治理项目中遇到过这种情况：我们有「数据查看员」「数据分析师」「数据管理员」三个角色。数据分析师应该拥有数据查看员的所有权限，数据管理员又应该拥有数据分析师的所有权限。如果用 RBAC0，我得重复定义三遍基础权限。用 RBAC1，直接让「数据分析师」继承「数据查看员」，「数据管理员」继承「数据分析师」，省事多了。
角色继承有两种形式：
- 树形继承：每个角色只有一个父角色，像一棵树。简单，但不够灵活。
- 图状继承：一个角色可以有多个父角色，形成有向无环图。灵活，但管理复杂度上升。
避坑指南：我曾经在一个项目中用了图状继承，结果角色关系乱成一团麻。后来我给自己定了个规矩：除非业务真的需要多继承，否则一律用树形继承。你想想看，角色关系越简单，排查权限问题就越容易。
3.4 RBAC2：加入约束，权限安全再升级
RBAC2 在 RBAC0 的基础上，增加了约束（Constraints）机制。说白了，就是给角色分配加一些「规矩」。
常见的约束类型有：
| 约束类型 | 说明 | 举个例子 |
|---|---|---|
| 互斥角色 | 一个用户不能同时拥有两个互斥的角色 | 「采购员」和「审批员」不能是同一个人 |
| 基数约束 | 限制某个角色最多能被多少用户拥有 | 「超级管理员」最多只能有 3 个人 |
| 先决条件角色 | 要拥有角色 A，必须先拥有角色 B | 要当「项目经理」，必须先当过「开发工程师」 |
| 会话约束 | 用户在一次会话中只能激活部分角色 | 登录时只能选一个角色，不能同时激活多个 |
为什么会需要这些约束？我举个例子你就明白了。在一个财务系统中，如果同一个人既负责「创建付款单」又负责「审批付款单」，那风险就大了去了。互斥角色就是用来防止这种「自己审批自己」的情况。
个人习惯：我在设计权限模型时，会先把互斥角色列出来，再考虑其他约束。因为互斥角色直接关系到合规和审计，优先级最高。
3.5 RBAC3：集大成者，RBAC1 + RBAC2
RBAC3 就是 RBAC1 和 RBAC2 的合体。它既有角色继承，又有约束机制。
你想想看，RBAC1 解决了角色层级管理的问题，RBAC2 解决了权限安全合规的问题。把两者结合起来，就是一个既灵活又安全的权限模型。
RBAC3 的约束不仅作用于角色分配，还作用于角色继承。比如，你可以定义：互斥角色不能出现在同一个继承链中。也就是说，如果角色 A 和角色 B 是互斥的，那么角色 A 的子角色也不能继承角色 B 的权限。
我在做一个大型数据平台的权限系统时，最终选的就是 RBAC3。因为用户量大（几千人），角色多（上百个），而且有严格的合规要求。RBAC3 既能通过角色继承减少重复配置，又能通过约束保证权限安全，两全其美。
一句话总结：RBAC3 = RBAC1（角色继承）+ RBAC2（约束机制）。它是 RBAC 家族中最完整、最强大的模型。
3.6 四个模型的关系与演进
四个模型的关系，可以用一张图来概括：
从这张图可以看得很清楚：
- RBAC0 是地基，所有模型都基于它。
- RBAC1 在地基上加了角色继承，解决层级管理问题。
- RBAC2 在地基上加了约束机制，解决安全合规问题。
- RBAC3 把两者合二为一，是最完整的模型。
3.7 如何选择？我的建议
很多同学会问：那我到底该用哪个模型？
我的建议是：从简单开始，按需升级。
- 如果你的系统只有几十个用户，角色不超过 10 个，权限关系简单——RBAC0 就够了。别为了炫技上复杂的模型。
- 如果角色之间有明显的层级关系，比如「普通用户 → 高级用户 → 管理员」——考虑 RBAC1。它能帮你省掉大量重复配置。
- 如果系统涉及敏感操作，有合规要求，需要防止权限滥用——考虑 RBAC2。互斥角色和基数约束是刚需。
- 如果以上情况都有，用户量大、角色多、合规严——直接上 RBAC3。虽然实现复杂度高一些，但长期来看是最省心的。
我曾经踩过的坑：在一个项目中，我一开始用了 RBAC0，后来发现需要角色继承，就硬生生在代码里加了个「伪继承」——用 if-else 判断角色层级。结果代码越来越乱，最后不得不重构。所以我的建议是：提前想清楚未来 1-2 年的需求，别为了省事埋下技术债。
3.8 小结
RBAC 的四个模型，说白了就是一套「从简单到复杂」的权限解决方案。RBAC0 是基础，RBAC1 加继承，RBAC2 加约束，RBAC3 是合体。理解它们的关系，能帮你在实际项目中做出更合理的选择。