3. 授权模型：RBAC（基于角色的访问控制）详解、权限矩阵设计
好，咱们来聊聊授权模型。说实话，权限管理这块，RBAC 是我在项目里用得最多的模型，没有之一。为什么？因为它够简单、够实用。你想想看，一个 ERP 系统里可能有几百号人，要是每个人单独配权限，那不得配到天荒地老？
3.1 RBAC 的核心思想
RBAC 说白了就是一句话：用户不直接拥有权限，而是通过角色来获得权限。用户和权限之间，隔了一层「角色」。
我习惯把 RBAC 拆成三个要素：
- 用户（User）：系统的操作者，比如张三、李四
- 角色（Role）：职责的集合，比如采购员、仓库管理员
- 权限（Permission）：对资源的操作，比如「创建采购订单」、「审核入库单」
它们的关系是这样的：
用户 → 角色 → 权限嗯，这里要注意：一个用户可以有多个角色，一个角色也可以有多个用户。这就是典型的多对多关系。
核心原则：权限只分配给角色，不直接分配给用户。用户通过扮演角色来获得权限。
3.2 RBAC 的三种模型
我在项目中遇到过不少团队，一上来就想搞复杂的权限模型。我个人建议，先从基础模型开始，不够用了再升级。RBAC 一般分三种：
3.2.1 RBAC0：基础模型
这就是最基础的版本。用户-角色-权限，三层结构。大部分中小型 ERP 系统用这个就够了。
举个例子：
用户：张三
角色：采购员
权限：创建采购订单、查看供应商列表、修改采购订单张三登录系统后，只能看到采购相关的菜单和功能。他看不到财务模块，也看不到仓库模块。这就是 RBAC0 的典型应用。
3.2.2 RBAC1：角色分级模型
这个模型引入了角色继承的概念。说白了，就是角色可以有上下级关系。
我曾经在一个制造企业的项目里用过这个。他们的组织架构是这样的：
- 采购总监 → 拥有所有采购权限
- 采购经理 → 拥有大部分采购权限，但审批额度有限
- 采购员 → 只能创建和查看采购订单
用 RBAC1 的话，我只需要定义好角色层级，高级角色自动继承低级角色的权限。省事不少。
采购总监（继承采购经理 + 采购员的所有权限）
└── 采购经理（继承采购员的所有权限）
└── 采购员（基础权限）3.2.3 RBAC2：约束模型
这个模型加了约束条件。最常见的有两种：
- 互斥角色：一个人不能同时拥有两个互斥的角色。比如，不能既是采购员又是审批员，防止自己采购自己审批。
- 基数约束：一个角色最多只能有几个人。比如，「总经理」这个角色只能有一个人。
我的经验：RBAC2 的互斥约束特别适合财务系统。我曾经帮一个客户设计权限时，就强制要求「制单人」和「审核人」不能是同一个人。这个约束直接写死在权限引擎里，比靠人工自觉靠谱多了。
3.3 权限矩阵设计
好了，理论说完了，咱们来点实际的。权限矩阵，说白了就是一张表，横轴是资源（菜单、按钮、数据），纵轴是角色，交叉点就是权限。
我习惯用这样的格式：
| 资源/操作 | 采购员 | 采购经理 | 仓库管理员 | 财务人员 |
|---|---|---|---|---|
| 采购订单-创建 | ✓ | ✓ | ✗ | ✗ |
| 采购订单-审核 | ✗ | ✓ | ✗ | ✗ |
| 入库单-创建 | ✗ | ✗ | ✓ | ✗ |
| 付款申请-创建 | ✗ | ✗ | ✗ | ✓ |
你可能会问：这个矩阵怎么落地到代码里？我一般用位运算或者 JSON 配置。给你看个简单的例子：
// 权限定义（用位运算）
const PERM_CREATE = 1; // 0001
const PERM_READ = 2; // 0010
const PERM_UPDATE = 4; // 0100
const PERM_DELETE = 8; // 1000
// 角色的权限值
const ROLE_PURCHASER = PERM_CREATE | PERM_READ; // 0011 = 3
const ROLE_MANAGER = PERM_CREATE | PERM_READ | PERM_UPDATE; // 0111 = 7
// 检查权限
function hasPermission(rolePerm, requiredPerm) {
return (rolePerm & requiredPerm) === requiredPerm;
}
console.log(hasPermission(ROLE_PURCHASER, PERM_CREATE)); // true
console.log(hasPermission(ROLE_PURCHASER, PERM_DELETE)); // false避坑指南：我曾经在一个项目里，把权限矩阵直接写死在代码里。结果客户上线后第三天就要调整权限，我改代码改到凌晨三点。后来学乖了，权限矩阵一定要做成可配置的，存数据库或者配置文件里。别问我怎么知道的。
3.4 权限矩阵设计的三个原则
做了这么多年权限设计，我总结了三个原则，分享给你：
- 最小权限原则：只给用户完成工作所需的最小权限。多一个都不要给。
- 职责分离原则：关键操作必须由不同的人完成。比如创建和审核不能是同一个人。
- 可审计原则：所有权限变更和敏感操作都要有日志。出了事能追溯。
嗯，这三个原则说起来简单，但真正落地的时候，你会发现很多细节。比如最小权限原则，你得先搞清楚每个岗位到底需要什么权限。我一般会拉上业务部门一起过一遍流程，把每个节点的操作都列出来，然后再决定给什么权限。
3.5 小结
RBAC 不是什么高深的技术，但它确实解决了权限管理里最核心的问题：如何高效、安全地管理大量用户的权限。权限矩阵则是把 RBAC 落地到具体系统里的工具。
我个人建议，刚开始做权限设计时，先用 RBAC0 搭好基础框架。等业务复杂了，再考虑引入角色继承和约束。别一上来就搞得太复杂，容易把自己绕进去。
下一章，咱们聊聊权限管理的另一个重要话题：数据权限。说白了，就是同一个角色的人，能看到哪些数据、不能看到哪些数据。这个在实际项目里坑更多，到时候我好好给你讲讲。