RBAC 权限模型实战：从 ACL 踩坑到 RBAC3 落地（2026）

今年我接手过一个后台开发，权限是用 ACL 写的——每个用户挂一串资源+操作。上线两周，甲方提了个需求：「把某些区的销售都加上订单导出」。我打开配置一看，47 个人，每人改一遍。改完我坐那想，这不对劲。后来我把权限层换成了 RBAC 权限模型，同样的需求改一行就完事。这篇文章是我那一次重构的复盘，也把 RBAC 的几个层次一次讲清楚。点个收藏，我们开始。

一、先回答一个问题：RBAC 到底解决什么

很多人会回答「管权限」。这个答案放在面试里能过，放在工程里会出事。我自己的结论是：

RBAC 权限模型解决的不是「有没有权限」的问题，而是「权限变动成本」的问题。

把权限直接绑到用户身上（ACL 模型），加一个人、改一个人、撤一个人都是 O(1) 的，但「批量改一类人」是 O(N) 的，而且容易漏。把权限绑到角色上、人只挂角色，那么"批量改一类人"就是改一次角色，N 个人同时生效。这就是 RBAC 的核心收益。

ACL（Access Control List，访问控制列表）：一种把权限直接挂到具体资源上的老模型，每条规则形如「资源 X 允许用户 Y 做 Z」。你可以理解为「门上贴名单，谁进谁在名单上」。

RBAC（Role-Based Access Control，基于角色的访问控制）：把权限绑到角色上，用户只和角色挂钩，角色再拥有权限。你可以理解为「门上贴工牌级别，人凭工牌进」。

我画一张图，你看完就知道这两种差别有多大：

左边的 ACL 写法，张三李四各自挂一串权限，运维改起来要一条条点。右边的 RBAC 写法，张三只挂「运营」这个角色，李四挂「主管」，权限都在角色上。改运营能干啥，所有运营一次性跟着变。

可能有人会问：那 ACL 是不是就该淘汰了？

不是。ACL 适合「资源特别碎、每个资源的 owner 都不一样」的场景，比如 Linux 文件的权限位、对象存储桶里的单条授权。RBAC 适合「角色相对固定、人员流动频繁」的中后台业务。两者不是替代，是分工。

二、RBAC 权限模型的三件套：用户、角色、权限

RBAC 的最小可用形态叫 RBAC0，就三个东西：用户（User）、角色（Role）、权限（Permission）。权限绑资源+操作，比如 order:read、order:write、report:export。

三件事的关系是两组多对多：用户和角色多对多（一个人可以兼多个角色），角色和权限多对多（一个角色可以拥有一组权限）。落地到表就是 user、role、permission、user_role、role_permission 五张表，足够你跑通 80% 的中后台。

我自己的代码里，权限不直接写成"读订单"，而是拆成 resource + action 两列。这样后面前端要按资源过滤、按操作过滤都好做。比如 resource=order, action=export，比一个字符串 order:export 灵活得多。

三、RBAC0 到 RBAC3：什么时候需要哪一档

这是面试和实战都最容易答含糊的地方。我先给一张演进图，再逐个说人话。

RBAC0：最基础的三件套，能跑通用户-角色-权限。一个小公司内部系统，用 RBAC0 完全够。

RBAC1：在 RBAC0 上加了角色继承。高级经理自动继承经理的权限，经理继承员工的权限，不用重复定义。

RBAC2：在 RBAC0 上加了约束。比如「财务和审计不能是同一个人」「一个项目只能有一个经理」。

RBAC3：RBAC1 + RBAC2，既要继承又要约束，大型企业的方案。

我给你列个对比表，怎么选一目了然：

我见过不少团队一上来就要 RBAC3，结果约束规则写到一半发现业务自己也说不清"先决条件"是啥。我的建议是：从 RBAC0 起步，等业务真的被某一类问题反复折磨了，再加对应的能力。别为了显得专业提前上复杂度。

四、角色继承：别让"高级经理"重复造轮子

RBAC1 解决的是「重复定义」的痛。我举个我吃过的亏：最早我把「经理」和「高级经理」当两个独立角色，各自挂一坨权限。后来公司要改"所有员工都能看公司公告"——我得改 3 个角色。如果当时用了继承，改"员工"一个角色就够了。

继承是传递的：高级经理继承经理、经理继承员工，那么高级经理自动拥有员工的所有权限。在表设计上，role 表加一列 parent_id 指向父角色就行，查权限时沿父链向上递归合并。

但要提醒一点：继承不要太深。我见过一家公司角色继承链 5 层，结果权限算下来谁也说不清"高级总监到底能不能导出报表"。我自己定的规矩是继承层级不超过 3 层，再深就拆角色或者用组合。

可能有人会问：继承和直接把多个角色都挂给一个人，有啥区别？

区别在「变动成本」。给一个人挂 3 个角色是 N 次操作，给一个角色继承另一个角色是 1 次操作、影响所有挂这个角色的人。当你需要"一类人统一加权限"时，继承是免费的红利。

五、约束：为什么审计和财务不能是同一个人

RBAC2 加的是「规则」。最常用的三种约束我直接给结论：

1. 互斥角色（Mutual Exclusion）：某些角色不能同时属于一个人。最经典就是财务 + 审计——一个人既录付款又复核付款，账就有动手脚的空间。
2. 先决角色（Prerequisite）：要拿 B 角色必须先有 A 角色。
3. 基数约束（Cardinality）：一个角色最多给 N 个人，或一个人最多挂 N 个角色。

互斥约束的代码实现不复杂，加一张 role_constraint 表，存「角色 A 与角色 B 互斥」一条规则即可，分配角色前查一下冲突表。我自己在金融项目里就用这一招过合规审计，审计员看了直点头。

但要注意一个坑：互斥要在「分配时」和「查询时」都校验。只在分配时挡住不够，历史数据可能已经违规，要定期跑一个对账任务，把"同时持有互斥角色"的人捞出来。

六、用户组：批量加人的救星

到这一步你已经能跑 RBAC3 了，但还会遇到一个恶心场景：销售部 30 个人，都要挂"销售员"角色。新来一个销售，HR 还得记得给他挂角色；HR 忘了，新人就啥都干不了。

用户组（User Group） 不是 RBAC 标准里的概念，但几乎所有落地 RBAC 的中台都加了。它把「一群同质用户」聚合起来，对组分配角色，组内成员自动继承。

生活化比喻：用户组就是「HR 拉了个工作群」，群里的人自动有群的权限，HR 只要管「谁进群」，不用管「群里发了什么角色」。

表结构上多两张：user_group、user_group_member，再加一张 group_role 把组和角色关联起来。员工入组后，权限计算时把组角色一并合并进「该用户的生效角色集」。新人入离职就是 group member 的一行 INSERT/DELETE，权限完全不用动。

七、四种权限粒度：菜单/操作/数据/字段

到这里 RBAC 的"骨架"就齐了，但很多团队上线后发现还差一口气——权限怎么落不到按钮上？这是「权限粒度」的问题。我把实战中常用的四种粒度列出来：

1. 菜单权限：控制后台左侧菜单和页面是否可见。粒度粗，挡"误入"，但挡不住接口直接调。
2. 操作权限：控制按钮（新增/删除/导出）和后端接口是否可调。这是真正"卡口"的地方，必须在后端校验，前端只是 UX。
3. 数据权限：控制能看到哪些范围的数据——本部门、本城市、全公司、自定义。这块最容易漏设计，很多人到上线才发现"销售 A 能看到销售 B 的客户"。
4. 字段权限：控制字段是否可见/可编辑。比如薪资字段对 HR 可见、对其他员工不可见。

我个人的落地顺序是：操作权限 > 数据权限 > 菜单权限 > 字段权限。操作权限是底线（不校验等于裸奔），数据权限是业务正确性，菜单权限是体验，字段权限是锦上添花。

数据权限的实现我推荐用「规则表达式 + 查询改写」：在角色上挂一个数据范围规则，比如 dept_id = ${user.dept_id}，然后在查询拦截器里自动把这个条件 AND 进 SQL。这样业务代码不感知，新规则加进来零侵入。

八、落地到表：一份能跑的 ER 设计

讲了这么多模型，最后给一份我项目里在用的表结构，你拿去改改就能用。

核心 8 张表：

• user：用户主表
• role：角色表，含 parent_id（继承用）
• permission：权限表，拆 resource + action
• user_role：用户-角色多对多
• role_permission：角色-权限多对多
• user_group：用户组表
• user_group_member：组-用户多对多
• group_role：组-角色多对多

加约束的话，再补 role_constraint（存互斥/先决规则）和 role_inherit（如果继承关系是多父角色就用独立表，单父用 parent_id 就够）。

权限计算的核心是「拿一个用户的所有生效角色」：先查 user_role，再查用户所在的所有 user_group_member 对应的 group_role，最后沿 role.parent_id 向上递归合并父角色。把这一坨角色 id 收齐后，再 role_permission join 出权限集。

一段示例 SQL，给你看「某用户所有生效权限」怎么算（MySQL 8+，用 CTE 递归）：

-- 示例：查用户 1001 的所有生效权限
WITH RECURSIVE user_roles AS (
  -- 直接挂的角色
  SELECT role_id FROM user_role WHERE user_id = 1001
  UNION
  -- 通过用户组挂的角色
  SELECT gr.role_id FROM user_group_member gm
    JOIN group_role gr ON gr.group_id = gm.group_id
    WHERE gm.user_id = 1001
),
role_chain AS (
  -- 沿继承链向上
  SELECT role_id FROM user_roles
  UNION
  SELECT r.parent_id FROM role_chain rc JOIN role r ON r.id = rc.role_id
    WHERE r.parent_id IS NOT NULL
)
SELECT DISTINCT p.resource, p.action
FROM role_chain rc
JOIN role_permission rp ON rp.role_id = rc.role_id
JOIN permission p ON p.id = rp.permission_id;

这段 SQL 在我这边 200ms 内能跑完（用户 ~5000、角色 ~80、权限 ~600）。生产建议加 Redis 缓存，按 user_id 缓存权限集，5 分钟 TTL，角色变更时主动清。

收尾：RBAC 不是终点，是起点

回到开头那句话：RBAC 权限模型解决的不是"有没有权限"，而是"权限变动成本"。从 RBAC0 到 RBAC3、再到用户组和数据权限，每加一层能力都是为了把某一类"频繁又容易出错的手工操作"沉淀进模型里。如果你只记一句话，就记这句——让权限跟着角色走，而不是跟着人走。

如果你的业务还涉及"按属性动态判断"（比如"工作日 9-18 点才能导出"），那 RBAC 就到头了，下一站是 ABAC（基于属性的访问控制）。这个我下篇再展开。