权限模型基础：从RBAC到ABAC
权限模型这东西，说白了就是一套规则——谁、能干什么、不能干什么。我见过太多团队一上来就撸代码写死权限判断，结果半年后改得想哭。今天咱们把两个主流模型讲透：RBAC 和 ABAC。
RBAC 模型详解
RBAC（Role-Based Access Control）是目前最普及的权限模型。它的核心思想就一句话：把权限分配给角色，再把角色分配给用户。用户不直接跟权限打交道，中间隔了一层角色。
核心三要素
- 用户（User）—— 谁在操作
- 角色（Role）—— 用户的身份标签
- 权限（Permission）—— 能做什么操作
举个例子。你公司的系统里有「管理员」「编辑」「访客」三个角色。管理员能增删改查，编辑只能改和查，访客只能看。用户张三被分配了「编辑」角色，那他就只能改和查。简单吧？
我在项目中遇到过一家创业公司，初期就两个角色：管理员和普通用户。后来业务膨胀到十几个角色，权限配置乱成一锅粥。嗯，这就是典型的「角色爆炸」——角色定义太细，反而失去了抽象的意义。
我的建议：角色数量控制在 5-10 个以内。超过这个数，就该考虑是不是角色粒度太细了，或者需要引入属性权限了。
ABAC 模型简介
ABAC（Attribute-Based Access Control）比 RBAC 灵活得多。它不看角色，而是看属性——用户的属性、资源的属性、环境的属性。
举个例子：
- 「只有部门经理才能查看本部门员工的薪资」
- 「只有在上班时间才能修改生产环境的配置」
这些规则用 RBAC 很难表达，但 ABAC 天生就支持。ABAC 的决策公式大致是：
允许访问 = 用户属性 匹配 资源属性 且 环境属性 满足条件我曾经在一个金融项目中用 ABAC 实现了「客户经理只能查看自己管辖客户的交易记录，且只能在工作日 9:00-18:00 导出报表」。如果用 RBAC，得建几十个角色才能覆盖这些组合场景。
注意：ABAC 虽然灵活，但性能开销大。每次访问都要计算属性匹配，规则多了容易变成「规则地狱」。我建议中小型系统先用 RBAC，等遇到复杂场景再局部引入 ABAC。
用户-角色-权限关系设计
这是 RBAC 落地的核心。我习惯用五张表来建模：
| 表名 | 说明 | 关键字段 |
|---|---|---|
| user | 用户表 | id, username, status |
| role | 角色表 | id, name, description |
| permission | 权限表 | id, resource, action |
| user_role | 用户-角色关联 | user_id, role_id |
| role_permission | 角色-权限关联 | role_id, permission_id |
为什么用五张表而不是三张？因为用户和角色是多对多，角色和权限也是多对多。直接合并成一张大表，维护起来就是噩梦。我曾经接手过一个项目，把用户角色权限全塞在一张表里，一个用户有 5 个角色就存 5 行，改个角色名要扫全表——那滋味，谁改谁知道。
下面这张图能帮你理清关系：
权限的粒度划分
权限粒度，就是你能控制到多细。我一般把它分成三个层次：
| 粒度 | 例子 | 适用场景 |
|---|---|---|
| 粗粒度 | 「能否访问订单模块」 | 菜单、页面级别的权限控制 |
| 中粒度 | 「能否创建订单」「能否删除订单」 | 按钮、操作级别的权限控制 |
| 细粒度 | 「只能查看自己创建的订单」 | 数据行级别的权限控制（行级权限） |
粗粒度最简单，用 RBAC 就能搞定。细粒度最复杂，往往需要结合 ABAC 或者数据过滤规则来实现。
避坑指南：我曾经在一个项目中把所有权限都设计成细粒度，结果配置页面有上百个 checkbox，管理员根本不知道怎么配。后来我改成「粗粒度控制入口，细粒度控制数据」，用户体验好多了。
你想想看，一个电商系统：
- 粗粒度：运营人员能进入「订单管理」页面
- 中粒度：运营人员能「查看」和「导出」订单，但不能「修改」和「删除」
- 细粒度：运营人员只能查看「自己负责区域」的订单
这三个层次叠加起来，才是完整的权限体系。我个人习惯先定粗粒度，再逐步细化。别一上来就钻细粒度，容易把自己绕进去。
嗯，这一章的内容就到这里。RBAC 和 ABAC 是权限系统的地基，搞懂了它们，后面讲行级权限就好理解了。