RBAC 模型核心概念：用户、角色、权限三要素，角色层级与继承

好，咱们正式开始聊 RBAC 的核心。

很多人一上来就跟我讲权限矩阵、用户组、资源标识符。其实没必要搞那么复杂。RBAC 说白了就围绕三个东西转：用户、角色、权限。你把这个三角关系捋清楚了，后面所有的设计都是水到渠成。

我记得我刚入行那会儿，有个老项目权限管理完全是硬编码 —— “if user.id == admin then allow”。那代码我看了都想哭。后来重构时我坚持切到 RBAC，代码量直接砍掉一半，而且业务方再也没因为“加个新角色就要改代码”来找过我麻烦。

1. 三要素：用户、角色、权限

咱们先一个个拆开看。

要素	定义	我的一句话理解
用户	系统的操作者。可以是人、服务账号、API 调用方。	“谁”在干活。
角色	一组权限的逻辑集合。比如“审核员”、“财务经理”、“系统管理员”。	“岗位”标签。用户靠它拿到能力。
权限	对某个资源的操作许可。例如“创建订单”、“删除退款记录”、“查看财务报表”。	“能做什么”的原子单位。

实践里有两种常见的关联方式：

• 用户 → 角色 → 权限（标准做法，中间隔一层角色）
• 用户 → 权限（直接在用户上挂权限，不推荐）

我个人的习惯是永远走角色这一层。为什么呢？你想想看，公司 100 个用户，每个人都是“财务审核员”这个角色。某天财务制度变了，审核员不能删除凭证了。如果你把删除凭证这个权限直接挂在 100 个用户上——好嘛，你得改 100 次。但如果你用角色，只需要改一次角色的权限定义。这才是 RBAC 的真正价值。

2. 角色层级与继承

讲完三要素，我要重点说说角色层级。这东西很多人忽略了，结果系统设计出来特别死板。

什么叫角色层级？说白了就是角色之间有“上下级”关系。上级角色自动拥有下级角色的全部权限。

为什么会这样？我举个例子：你公司有“普通员工”和“主管”两个角色。主管除了自己的权限外，是不是也需要能执行普通员工的操作？比如普通员工能“提交报销单”，主管也应该能替员工提交。最直接的实现方式就是让“主管”继承“普通员工”的所有权限。

我在项目中遇到过这样一个坑：没做角色继承，而是把主管该有的权限手动复制了一遍。结果呢？普通员工的权限升级了（比如增加了“电子发票”功能），主管那边完全没同步，上线后一堆主管投诉说功能灰掉了。这就是角色层级设计不到位带来的运维灾难。

角色继承的类型一般有两种：

这两种继承都遵循一条基本规则：如果角色 A 继承了角色 B，那么权限集合 Perm(A) ⊇ Perm(B)。上级只能多不能少，逻辑上才能在业务中站住脚。

3. 核心关系：一张图看清

说了这么多，我画一张图帮你把概念串起来。这张图我管它叫“RBAC 三要素与层级继承关系图”，我们团队做权限设计复盘时必贴这张图。

别小看这几行框和箭头。你把用户、角色、权限这三层画清楚，再把角色之间的继承箭头标明白，整个系统的权限架构就一目了然了。业务方拿着这张图跟你对需求，基本不会跑偏。

你看这张图：用户在最上层，每个用户挂到一个或多个角色上。角色在中间层，它们之间有层级继承的关系（箭头方向表示继承方向）。最下面是权限原子。整个模型就这么三层，清晰得不能再清晰了。

实际操作时，我建议你把“角色层级”画成树状图或者有向无环图（DAG），千万别画成循环引用。我曾经见过一个系统，角色 A 继承 B，B 继承 C，结果 C 又继承 A —— 权限查询直接死循环。排查了半天才知道运维配错了。所以现在我的团队里有个硬性规定：角色继承关系必须由代码校验，出现循环依赖直接报错，不允许保存。

4. 什么时候用层级，什么时候不用？

不是所有场景都需要角色层级。我个人的判断标准是这样的：

• 需要层级继承的场景：管理组织架构分明、岗位之间有明确的上下级汇报关系、权限存在“上级能帮下级做的事”这种业务需求。
• 不需要层级继承的场景：纯粹的职能角色之间没有上下级关系（比如“客服”和“技术”是平级的），或者角色数量少且交叉很少。扁平化组织里硬上继承反而增加复杂度。