一、权限模型总览：为什么需要权限系统？
说实话，我见过太多系统在上线后才开始补权限模块。那时候改起来，真是牵一发动全身。你想想看，一个没有权限控制的系统，就像一栋没有门锁的大楼——谁都能进，谁都能拿东西。
权限系统解决的核心问题就三个：谁能做什么，能看到什么，能改什么。听起来简单，但落地时坑特别多。
权限系统的三大核心价值：
- 安全合规：满足等保、GDPR 等监管要求，防止数据泄露
- 职责分离：避免一人身兼多职导致的舞弊风险
- 精细管控：不同角色、不同场景下，数据可见范围不同
我在项目中遇到过一家金融客户，上线前三个月才想起做权限。结果呢？所有接口都得加鉴权，数据库里每个表都得考虑行级过滤。那段时间，团队几乎天天加班到凌晨。所以，权限系统一定要前置设计，千万别等代码写完了再补。
1.1 从粗粒度到细粒度：权限模型的演进
权限模型不是一天建成的。我把它分成三个阶段，你可以对照看看自己的系统处在哪个阶段。
| 阶段 | 模型 | 控制粒度 | 典型场景 |
|---|---|---|---|
| 第一阶段 | ACL（访问控制列表） | 用户级 | 文件系统、早期 CMS |
| 第二阶段 | RBAC（基于角色的访问控制） | 角色级 | 企业管理系统、SaaS 平台 |
| 第三阶段 | ABAC（基于属性的访问控制） | 属性级 | 金融风控、医疗数据、多租户系统 |
ACL 太原始了，每个用户都得单独配权限，维护成本极高。RBAC 通过角色解耦，算是目前最主流的方案。但 RBAC 有个硬伤——它管不了数据行级别的差异。比如同样是“销售经理”，A 区域的只能看华东数据，B 区域的只能看华南数据。这时候，就得靠 ABAC 或者行列权限模型了。
1.2 RBAC、ABAC、行列权限模型，到底怎么选？
很多同学问我：“老师，我们该用 RBAC 还是 ABAC？”我的回答是：别非此即彼，它们可以组合使用。
先看一张对比表，你就明白了。
| 维度 | RBAC | ABAC | 行列权限模型 |
|---|---|---|---|
| 控制对象 | 角色 | 属性（用户、资源、环境） | 行 + 列（数据级） |
| 灵活性 | 中 | 高 | 高 |
| 性能开销 | 低 | 中 | 中高 |
| 维护成本 | 低 | 高（策略多） | 中 |
| 适用场景 | 功能权限为主 | 复杂动态权限 | 数据安全、隐私保护 |
我个人习惯这样划分：功能权限用 RBAC，数据权限用行列模型，复杂策略用 ABAC。三者不是替代关系，而是互补关系。
避坑指南：我曾经在一个项目中，试图用纯 ABAC 替代所有 RBAC 逻辑。结果策略规则写了上千条，每次权限判断都要解析几十个属性，接口响应时间从 20ms 飙到了 200ms。后来老老实实把 80% 的通用权限切回 RBAC，只对敏感数据用 ABAC，性能才恢复正常。
1.3 行列权限模型：到底在解决什么问题？
说白了，行列权限模型就是在数据库层面控制你能看到哪些行、哪些列。
- 行权限：控制数据行的可见范围。比如“销售只能看自己的订单”、“经理能看本部门的订单”。
- 列权限：控制数据列的可见范围。比如“客服能看到客户手机号，但运营只能看到脱敏后的号码”。
举个例子，一张订单表有 10 个字段。普通员工只能看到 5 个基础字段，而且只能看自己负责的 100 条订单。部门经理能看到全部 10 个字段，但只能看本部门的 500 条订单。CEO 能看到所有 2000 条订单和全部字段。这就是典型的行列权限控制。
注意：行列权限不是在应用层做 if-else 判断，而是在数据访问层统一拦截。否则，每个开发写出来的权限逻辑都不一样，后期维护就是灾难。
1.4 课程整体架构：30 章，从入门到实战
这门课一共 30 章，我把它分成四个模块。你可以先看看整体结构，心里有个底。
四个模块层层递进。基础篇帮你打好理论地基，进阶篇深入技术细节，实战篇带你落地一个完整的权限中台，扩展篇则从架构师视角看权限系统的未来演进。
嗯，这里要注意：每章都有可运行的代码示例，不是纯理论。我会用 Spring Boot + MyBatis 作为主技术栈，但核心思想是通用的，换成其他语言或框架也一样适用。
1.5 学完这门课，你能得到什么？
- 彻底搞懂 RBAC、ABAC、行列权限模型的原理与差异
- 掌握行级过滤、列级脱敏的落地实现方案
- 能独立设计一套支持百万级用户、千万级数据的权限系统
- 避开我在项目中踩过的那些坑——尤其是性能和安全方面的
一句话总结：权限系统不是功能堆砌，而是架构设计。这门课的目标，就是让你从“会配权限”变成“会设计权限系统”。