# 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，基于角色的访问控制）**：把权限绑到角色上，用户只和角色挂钩，角色再拥有权限。你可以理解为「门上贴工牌级别，人凭工牌进」。

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

![fig-1.png](https://developer.qcloudimg.com/http-save/yehe-12591818/81d7c31bfce0e570a06724fb8a6a8deb.png)

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

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

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

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

![fig-2.png](https://developer.qcloudimg.com/http-save/yehe-12591818/dc4f3d6abe1b63cf7183587bf6a99434.png)

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

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

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

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

![fig-3.png](https://developer.qcloudimg.com/http-save/yehe-12591818/3041f0a6c0f4b261f2c52018869951a3.png)


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

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

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

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

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

| 模型 | 关键能力 | 适用场景 | 落地成本 |
|------|---------|---------|---------|
| RBAC0 | 用户-角色-权限三元组 | 中小后台、人员 < 100 | 低，5 张表 |
| RBAC1 | 角色继承层次 | 有清晰职级体系的公司 | 中，加角色自引用 |
| RBAC2 | 互斥/先决/基数约束 | 金融、审计、合规要求高 | 高，需要约束引擎 |
| RBAC3 | 继承 + 约束全要 | 大型企业集团 | 高，需要完整权限中台 |

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

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

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

![fig-4.png](https://developer.qcloudimg.com/http-save/yehe-12591818/b011bd8f67fe2807c240688f0b2e09da.png)

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

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

> **可能有人会问：继承和直接把多个角色都挂给一个人，有啥区别？**
>
> 区别在「变动成本」。给一个人挂 3 个角色是 N 次操作，给一个角色继承另一个角色是 1 次操作、影响所有挂这个角色的人。当你需要"一类人统一加权限"时，继承是免费的红利。

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

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

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

![fig-5.png](https://developer.qcloudimg.com/http-save/yehe-12591818/99e0f16d7ebce8b27c249951fc645fb4.png)

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

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

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

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

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

![fig-6.png](https://developer.qcloudimg.com/http-save/yehe-12591818/a998b4d40c360a45681dee72241ee033.png)

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

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

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

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


![fig-7.png](https://developer.qcloudimg.com/http-save/yehe-12591818/ccc849388503756a720aa3b2587a7019.png)


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

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

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

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

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

![fig-8.png](https://developer.qcloudimg.com/http-save/yehe-12591818/2351eb1ad1dc793c6f2db1e32e489575.png)


核心 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 递归）：

```sql
-- 示例：查用户 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（基于属性的访问控制）。这个我下篇再展开。



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

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

写过 ACL 才懂 RBAC 的好。本文把 RBAC 权限模型、RBAC0~3、角色继承、互斥约束、用户组、四类权限粒度一次讲透，并附可落地的表设计

后端

开发工具

职业发展

RBAC权限模型实战指南：从ACL到RBAC3的演进路径。文章深度解析RBAC如何降低权限变更成本，对比ACL与RBAC差异，详解RBAC0到RBAC3的适用场景，提供用户组、数据权限等实战方案，并附可落地的ER设计。适合中后台系统开发者学习权限系统设计，解决批量授权、角色继承等核心问题。

访问控制列表

对象存储

代码解释

Redis

Linux

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RBAC 权限模型实战：从 ACL 踩坑到 RBAC3 落地（2026）-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐