一、RBAC 概述：先搞懂权限这件事

权限管理，说白了就是一句话：谁，能做什么。

我刚入行时，公司还在用自己手写的权限判断——每个接口里都塞满了 if-else。当时觉得挺灵活的，后来项目一膨胀，代码直接变成一团乱麻。有一次，一个新同事不小心把财务导出的 Excel 接口配给了客服角色，险些酿成数据泄露事故。嗯，从那次以后，我就再也不瞎折腾权限设计了。

1.1 什么是 RBAC？

RBAC，全称 Role-Based Access Control，翻译过来是基于角色的访问控制。

它的核心思想，就是把权限赋给角色，再把角色赋给用户。

你想想看，你的公司里是不是每个人都有岗位？财务、HR、开发、运营。RBAC 就是把这个机制搬到了系统里。你不会直接跟张三说“你能看工资条”，而是跟“财务主管”这个角色说“你能看工资条”，然后让张三担任这个角色。

1.2 RBAC 的核心四要素

我在翻过不少项目代码后，发现很多人理解 RBAC 只停在了“用户有角色”这个层面。其实，完整的 RBAC 模型包含四个基本元素：

• 用户（User）：系统的操作者，比如张三、李四。一个人可以拥有多个角色。
• 角色（Role）：职责的抽象，比如“管理员”、“审计员”。它是权限的容器。
• 权限（Permission）：对某个资源的操作许可，比如“创建订单”、“删除用户”。
• 会话（Session）：用户登录后激活的角色集合。这点很容易被忽略，但它决定了“这次请求以什么身份执行”。

举个例子：

• 张三既是“普通用户”又是“内部测试员”。
• 他登录时，系统创建了一个会话。这个会话可以激活“普通用户”角色，也可以激活“内部测试员”角色。
• 如果他要进行一项高危操作（比如删除测试数据），系统会检查他当前激活的角色里有没有这个权限。

要素	含义	我见过的坑
用户	谁	用户离职后角色还在，新同事接替时忘记回收，权限就失控了
角色	什么身份	角色数量无限膨胀，最后比用户还多，丧失抽象意义
权限	做什么	权限粒度太细或太粗，都容易出问题
会话	现在激活什么身份	不少人直接用用户的所有角色做权限校验，忽略了最小权限原则

1.3 RBAC 与 ACL 的区别

ACL（Access Control List）是另一类权限模型。很多人会混淆这两个概念，其实它们的设计哲学完全不同。

ACL 的风格是：直接给用户挂权限。一个用户有一张权限列表，上面写着“张三：可以读订单、可以写订单”。这种方式在小系统里很直观，但是一旦用户数量多起来，管理成本会直线上升。

我曾经接手过一个用 ACL 的中型电商后台，两百个用户，每个人的权限表都是运维手动配的。后来人事变动频繁，新来的运营同事权限不够，离职的同事权限却一直没收。结果就是：要么业务卡住，要么存在巨大的安全风险。

RBAC 是怎么解决这个问题的？

对比维度	ACL	RBAC
管理对象	用户直接与权限绑定	通过「角色」这一层间接绑定
用户规模	适合 10 人以内的小团队	适合几十人以上的组织，甚至上万
权限变更	逐个修改用户的权限列表，非常繁琐	修改角色的权限，所有关联用户自动生效
审核与追溯	权限分散在各用户身上，难以盘点	角色权限清晰，审计时可以按角色批量审查
典型场景	文件系统、单机小工具	企业级 SaaS、CRM、ERP、后台管理

说白了，ACL 是“直接贴标签”，RBAC 是“先分好角色，再让人入座”。

到这里你应该感觉到了，RBAC 的本质是一种抽象。它把“谁”和“做什么”之间插入了一个稳定的中间层——角色。这样，用户的流动和权限的变更就不会互相干扰。

这张图你应该能读懂了：

• 用户登录后产生会话。
• 会话决定了当前激活了哪些角色。
• 角色上面绑定了具体的权限。

整个链路清晰、可追溯。这也是 RBAC 能成为企业级系统标配的根本原因。

1.4 什么时候该用 RBAC？

你可能会问：是不是所有系统都得用 RBAC？

我个人习惯这样做判断：

• 用户超过 20 人：手动配 ACL 已经力不从心了。
• 岗位职能相对固定：角色能稳定下来，RBAC 的抽象效果最好。
• 需要定期审计权限：RBAC 的角色清单就是天然的审查提纲。
• 系统会持续迭代新功能：新增权限时，只需要往对应的角色里挂就行了。

反之，如果你只是写个单机小工具，3 个人用，ACL 完全够用，别为了设计而设计。