RBAC 模型基础：拆开那层「铁三角」

做权限系统，绕不开 RBAC。我个人习惯把 RBAC 看成是「用户 - 角色 - 权限」三者的拧螺丝关系。说白了，就是让用户通过角色拿权限，而不是直接给用户贴一大串权限标签。你想想看，如果每个新员工入职，你都得手动配置他能点哪个按钮、不能看哪张报表——那简直是一场灾难。

我在项目里见过不少团队，一开始觉得 RBAC 太简单，结果业务复杂起来，权限改得一团乱。嗯，今天我们就先把这层关系彻底捋清楚。

核心三元组：用户、角色、权限

RBAC 的根基是三个家伙，记住这张表就够了：

它们之间的关系线也很清楚：用户被赋予角色，角色被赋予权限。这下用户就自动拥有了角色下的所有权限。我曾经遇到一个项目，某团队在数据库里直接写了一个「用户-权限」关联表，跳过了角色层。结果业务一扩张，权限条目上万，管理直接崩了。做 RBAC 千万别跳开角色这层。

权限的本质：原子与装配

先说说权限。权限的原子性很重要。我个人习惯把权限写成「资源 + 操作」的组合。

• 资源：比如订单、商品、用户信息、报表。
• 操作：CRUD——创建(Create)、读取(Read)、更新(Update)、删除(Delete)。

举个例子，「删除订单」就是一个权限。对应代码里，可能是 order:delete 这么个字符串。为什么要拆得这么细？

因为如果不原子，你会发现自己给一个人开了全部读写权限，他只是想改一条数据，却把整个表删了。嗯，这可不是开玩笑。

# 格式：资源:操作
order:create
order:read
order:update
order:delete

# 通配符也可以
order:*       # 订单全部操作
*:read        # 所有资源的读取权限

角色：权限的集装箱

角色就简单了，它是一个容器，里面装着一组权限。你想想看，面向对象编程里的类，角色差不多就是这个意思。比如「编辑」角色，里面塞了「文章:创建」「文章:编辑」「文章:发布」这些权限。

这里有个关键点：角色可以继承。我在项目中一般会做一个角色层级，比如「超级管理员」继承「管理员」的所有权限，再加一个审计权限。这样写代码，少写一堆 if 分支。

用户与角色的绑定：多对多

一个用户可以有多个角色，一个角色也可以有多个用户。这是标准的「多对多」关系。比如张工程师既是「开发」又是「项目管理员」，可以看代码，也能改项目配置。

这时候要注意一个坑：权限冲突。如果角色 A 允许删除，角色 B 禁止删除，用户同时有这两个角色，该听谁的？

我的处理方法是：默认取并集——只要有一个角色允许，就算允许。除非你有明确的白名单逻辑。我曾经在同事的代码里看到过互相覆盖的写法，结果用户权限时有时无，排查了一整天。嗯，这件事之后我就写了统一规则：所有角色权限叠加，不做减法。

一张图看懂三元组关系

上面说的这些，光看文字可能有点散。我画了一张图，把用户、角色、权限的流转关系卡在一起，你一看就明白。

这张图从上往下读：用户通过角色拿到权限，这就是 RBAC 最核心的流转路径。角色起了个中间层的作用，把管理复杂度降低了不止一个量级。

什么时候用 RBAC？

不是说所有场景都适合 RBAC。我个人经验里，以下情况 RBAC 很香：

• 用户数量多、角色类型比较稳定（比如企业级后台）
• 权限需要按岗位/职责批量分配（比如运营、财务、管理员）
• 需要审计谁有什么权限（角色集中管理，好查）

但如果权限规则极其动态，比如每几个小时换一套规则，或者完全按属性控制（ABAC），那 RBAC 会显得有点笨重。不过大多数业务系统，RBAC 够用了。

总结一下这一章的核心

嗯，现在回头捋一遍：

• 用户是系统操作者，角色是权限容器，权限是原子化的资源+操作。
• 用户和角色是多对多关系，角色和权限也是多对多。
• 权限命名用「资源:操作」格式，角色要控制数量别膨胀。

这章没有代码实战，但概念理不清，后面写角色继承、权限校验、数据权限都会东倒西歪。我见过太多人因为基础没打牢，兜了一大圈又回来重新学。说白了，RBAC 没那么玄，就是个中间层的思维。下功夫把这三个家伙的关系搞明白，后面会发现全是水到渠成的事情。