1. 权限模型概述
1.1 什么是权限控制？
权限控制，说白了就是解决一个问题：谁（Who）能对什么（What）做什么（How）。你想想看，一个系统里用户成千上万，有人能看工资单，有人能改订单状态，还有人是超级管理员啥都能干。如果不加控制，那不乱套了？
我刚开始做后端时，遇到过一个小问题。一个同事不小心把生产环境的删除接口暴露给了普通用户，结果客户把测试数据给清空了。嗯，从那以后我就明白，权限控制不是锦上添花，而是保命用的。
权限控制的本质是授权决策。当用户发起一个请求，系统需要判断：这个用户有没有资格执行这个操作？判断的依据通常包括用户身份、角色、资源属性、环境上下文等。决策结果要么放行，要么拒绝。
1.2 常见权限模型对比
业界主流的有三种模型：RBAC、ABAC、PBAC。我一个个说。
RBAC（基于角色的访问控制）
RBAC 把权限分配给角色，再把角色分配给用户。用户不再直接关联权限，而是通过角色间接获得。举例：给“销售经理”角色分配“查看客户报表”权限，A员工被授予“销售经理”角色，A就能看报表了。
这种模型最大的好处是管理简单。你只需要管好角色和用户的映射就行，权限变动只需要改角色，不用一个一个用户调。我之前在电商公司，人员流动频繁，用RBAC后入职只需要分配一个角色，离职收回角色，效率高很多。
ABAC（基于属性的访问控制）
ABAC 不再依赖角色，而是根据一堆属性来做决策。属性分四类：用户属性（部门、职级）、资源属性（文档密级、创建者）、环境属性（时间、IP、设备状态）、操作属性（读取、写入）。
举个例子：允许“市场部员工”在“工作时间（9:00-18:00）”从“公司内网”读取“密级为公开”的“市场资料”。你看，一条策略就能描述得非常精细。能实现细粒度、动态化的权限控制。
但代价也很明显：策略表达式复杂，维护成本高，执行时需要实时计算属性，性能开销大。我参与过一个金融项目，ABAC 的规则引擎跑一次权限判断要几十毫秒，后来不得不加缓存来扛。
PBAC（基于策略的访问控制）
PBAC 和 ABAC 有点像，但它更强调策略的集中管理。通常采用策略语言（如 XACML、Alfa）来描述权限规则，然后由策略决策点（PDP）统一计算。你可以把它理解成 ABAC 的“标准化版本”，适合复杂的跨系统权限场景。
不过说实话，PBAC 太重量级了。我接触过的中小团队几乎没有直接上 PBAC 的，除非是银行、政务这种必须对权限审计有严格合规要求的系统。
三种模型快速对比
| 维度 | RBAC | ABAC | PBAC |
|---|---|---|---|
| 核心概念 | 角色 | 属性 | 策略 |
| 管理复杂度 | 低 | 高 | 很高 |
| 粒度 | 粗 | 细 | 细 |
| 动态性 | 弱 | 强 | 强 |
| 性能 | 快 | 中等 | 慢 |
| 典型场景 | CRM、OA、内部系统 | 文档管理、云资源 | 金融、合规性要求高 |
从表格能看出来，RBAC 在简单性上完胜。但 ABAC/PBAC 能处理复杂场景。那问题来了：我们做实战课程，选哪个打底？
1.3 为什么选择RBAC作为实战基础
理由有三个，都是我实际踩坑后的体会。
- 上手快，适合教学。 我自己带新人时，RBAC 花 30 分钟就能讲透核心概念，再花半天就能搭一个可运行的原型。ABAC 讲完概念至少半天，实战至少一周。
- 覆盖 80% 的业务场景。 大部分企业级应用（后台管理、CRM、ERP、SaaS 平台）都可以用 RBAC 搞定。你想想看，一个系统里角色不超过 20 个，权限不超过 200 项，RBAC 完全够用。
- 可平滑扩展。 如果将来真的遇到细粒度需求，在 RBAC 基础上叠加属性约束（变成 RBAC+ABAC 混合模式）也是常见的做法。先打好底座，再往上盖楼。
下面这张图概括了三种模型的核心关系，以及我们选择 RBAC 的定位。