1. 权限模型基础：RBAC 模型介绍、用户-角色-权限关系、最小权限原则
权限管理，说白了就是「谁可以干什么」。你想想看，一个配方系统里，普通操作员能修改关键工艺参数吗？肯定不行。那怎么管？业界最成熟的做法就是 RBAC——基于角色的访问控制。我做了这么多年后台系统，RBAC 几乎成了权限设计的标配，几乎没有哪个正经系统能绕过它。
1.1 什么是 RBAC？
RBAC 的全称是 Role-Based Access Control。它的核心思路很简单：不直接把权限给用户，而是把权限给角色，再把角色给用户。
举个例子。你公司有 100 个配方工程师，如果每个人单独配置权限，改一次配方就要改 100 次。但如果你定义了一个「配方工程师」角色，把「修改配方」的权限挂在这个角色上，然后把这 100 个人都加入这个角色——嗯，一次配置，全员生效。我在项目中见过太多团队一开始图省事直接给用户挂权限，结果三个月后权限表乱成一锅粥，谁都不敢动。
1.2 用户-角色-权限关系
这三者的关系，我习惯用一个三层模型来理解：
| 层级 | 定义 | 举例 |
|---|---|---|
| 用户 | 系统的操作者，可以是人、服务账号或设备 | 张三、李四、配方审核机器人 |
| 角色 | 权限的集合，代表一类职责 | 配方管理员、质检员、只读查看者 |
| 权限 | 对某个资源的具体操作能力 | 「修改配方温度」「删除工艺步骤」「导出报表」 |
这里有个关键点：用户和角色是多对多关系。一个人可以同时拥有多个角色，一个角色也可以被多个用户持有。比如张三既是「配方管理员」又是「质检员」，这完全合理。
我曾经接手过一个遗留系统，他们把用户和权限直接绑定，结果一个用户离职，要手动清理几十条权限记录。换成 RBAC 之后，只需要把用户从角色里移除，所有权限自动回收。省心太多了。
1.3 最小权限原则
这个原则听起来很学术，其实就一句话：只给刚刚够用的权限，不多给一分。
为什么重要？你想想看，如果一个只负责查看配方的操作员，不小心被赋予了「删除配方」的权限——哪天他手滑点错了，整个生产线的配方数据就没了。这不是危言耸听，我在某制造企业做审计时，就遇到过因为权限过大导致误删工艺参数的事故，生产线停了整整两天。
最小权限原则在实际落地时，有几个具体做法：
- 按职责拆分角色：不要搞大而全的「管理员」角色，拆成「配方查看者」「配方编辑者」「配方审核者」
- 默认拒绝：所有权限默认关闭，只有明确授权才开放
- 定期审计：每季度检查一次角色-权限映射，清理过期或冗余的权限
- 临时提权：需要临时权限时，使用有时间限制的临时角色，到期自动回收
1.4 RBAC 模型结构图
下面这张图，把用户、角色、权限的关系画清楚了。我每次给团队讲权限设计，都会先画这张图。
1.5 配方场景中的 RBAC 落地
回到我们的课程主题——配方修改保护。在真实的配方管理系统中，我建议至少定义这几个角色：
| 角色 | 可操作权限 | 典型用户 |
|---|---|---|
| 配方查看者 | 查看配方、导出 PDF | 产线操作员、质检员 |
| 配方编辑者 | 查看 + 修改配方参数 | 工艺工程师 |
| 配方审核者 | 查看 + 审核/驳回修改 | 工艺主管 |
| 配方管理员 | 全部权限（含删除、版本回滚） | 系统管理员、研发负责人 |
1.6 小结
这一章我们聊了 RBAC 的核心思想：用户通过角色获得权限。最小权限原则告诉我们，权限要给得刚刚好，不多不少。下一章我们会深入具体的权限模型设计，看看怎么在代码里落地这些概念。
嗯，先消化这些。权限设计是后面所有内容的基础，基础打牢了，后面写代码才不慌。