RBAC 模型基础：角色、权限、用户关系
讲 RBAC 之前，我想先聊聊我踩过的一个坑。
几年前做企业内部系统，权限管理直接写死在代码里——if(user.role == "admin") {...}。刚开始就两个角色，挺爽的。后来加了运营、财务、审计，代码变成了 if-else 地狱。更惨的是，有个新业务要调整十多个接口的权限，改了两周，上线当晚就炸了。
从那以后，我再也不敢小看权限模型了。RBAC 这套东西，说白了就是帮我们把「谁」「能干什么」「怎么分的」理清楚。
角色 (Role) —— 权限的集合体
角色不是用户，也不是某个具体功能。
它是一组权限的「打包」。比如「运营专员」这个角色，包含了查看订单、编辑商品、导出报表这些权限。你不需要给每个人单独配权限，给角色就行了。
权限 (Permission) —— 最小粒度的操作
权限是 RBAC 的原子单位。常见的权限包括：
- 查看（read）
- 创建（create）
- 编辑（update）
- 删除（delete）
- 审批（approve）
注意，权限要能和数据范围绑定。比如「编辑订单」这个权限，可能还要区分「编辑自己的订单」还是「编辑所有订单」。这种细粒度我建议用「权限 + 数据范围」组合来实现，后面双人审批部分会专门讲。
用户 (User) —— 赋了角色的活人
用户就是具体的使用者。在 RBAC 里，用户不直接关联权限，而是通过「角色」间接获得权限。
举个例子：
用户A → 角色「财务主管」→ 权限[查看财务报表, 审批报销, 导出账目]
用户B → 角色「财务专员」→ 权限[查看财务报表, 录入报销]用户 B 没有审批权限，因为它关联的角色就没这个能力。这设计你看得清楚，也容易审计。
三者关系 —— 核心三角
把上面三个概念串起来，就是 RBAC 的经典三角：
| 概念 | 本质 | 一个例子 |
|---|---|---|
| 用户 (User) | 系统使用者 | 张三、李四 |
| 角色 (Role) | 权限的集合 | 财务主管、运营经理 |
| 权限 (Permission) | 最小操作单元 | 查看订单、删除商品 |
用户 ↔ 角色 (多对多)：一个用户可以有多个角色，一个角色也能属于多个用户。
角色 ↔ 权限 (多对多)：一个角色包含多个权限，一个权限也能出现在多个角色里。
用户不直接和权限挂钩，这就是 RBAC 的核心约束。
下面这张图把关系画清楚了：
RBAC 的优点，为什么要用它？
你想想看，如果没有角色，你要管几百个用户每人都有哪些权限，光维护就疯了。有角色之后：
- 方便批量调整：修改角色的权限，所有关联用户跟着变。
- 易于审计：查一个人有什么权限，只需要看他的角色；查一个权限谁在用，看角色下有哪些用户。
- 权限最小化：可以精细控制每个角色只配必要的权限，避免「Admin 满天飞」。
嗯，这里要注意一个细节：角色不宜太多。我在一个客户项目里见过 200 多个角色，每个角色只有一两个权限。那样角色就退化成「标签」了，失去了聚合的意义。我建议角色数量控制在 20 以内，如果超过 50 个，就该反思是不是把「岗位」和「角色」混了。
一个实际的配置样例
假设我们有个内容管理系统，用户、角色、权限的关联表如下：
| 用户 | 角色 | 关联权限 |
|---|---|---|
| 张编辑 | 内容编辑 | 创建文章、编辑草稿、查看已发布 |
| 李主编 | 内容主编 | 创建文章、编辑草稿、查看已发布、审核发布、撤销发布 |
| 王运营 | 运营专员 | 查看文章、置顶文章、推荐到首页 |
你会发现，张编辑和李主编都拥有「创建文章」权限，但李主编多了一个「审核发布」。这个差异是因为他们关联的角色不同，而不是直接在用户上加了标记。这就是 RBAC 的直观好处。
好了，RBAC 的模型基础差不多就这些。看似简单，但很多项目都栽在「用户直挂权限」或者「角色爆炸」上。后面几章我们会聊 RBAC 与双人审批集成时，怎么处理「谁可以批准」「审批链和角色怎么联动」这些更深的问题——但那是后话，先把基础打扎实再说。