1. 权限模型基础：什么是权限模型、为什么需要权限模型、权限模型的核心三要素

各位同学，咱们今天聊点实在的。权限模型这东西，说白了就是一套规则——告诉系统“谁能干什么”。

我刚开始做开发那会儿，觉得权限不就是if-else判断吗？后来在一个金融项目里被狠狠教育了一顿。用户乱点、数据泄露、审计不过……嗯，从那以后我才真正重视起权限设计。

1.1 什么是权限模型

权限模型，是一套结构化的规则体系。它定义了：

• 谁（用户/身份）
• 能访问什么（资源/数据）
• 能做什么操作（增删改查/执行）

你可以把它想象成一张门禁卡。卡本身是身份凭证，门是资源，刷卡的动作就是操作。没有这张卡，你进不去；有卡但权限不够，你也只能进特定区域。

我见过不少团队，一开始觉得权限“简单”，直接在代码里写死判断。结果业务一扩张，代码改得面目全非。你想想看，一个系统上线三年后，谁还记得某个if条件当初是为谁加的？

1.2 为什么需要权限模型

这个问题我问过很多学员。有人说“为了安全”，有人说“为了合规”。都对，但不够全面。

我个人习惯从三个维度来看：

维度	说明	真实案例
安全性	防止越权操作、数据泄露	某电商后台，普通运营能看到CEO的财务报表——这就是没权限模型的结果
可维护性	权限变更时，改配置不改代码	我曾经接手一个项目，加一个角色要改12个文件……后来重构用了RBAC，半小时搞定
审计合规	满足等保、GDPR等监管要求	金融行业审计必问：你们的权限矩阵在哪？谁审批的？谁授权的？

说白了，没有权限模型的系统，就像一栋没有门锁的大楼。好人进去方便，坏人进去也方便。

1.3 权限模型的核心三要素

不管多复杂的权限系统，拆到最底层，就三个东西：用户、角色、权限。

我习惯用一个三角形来理解它们的关系：

1.3.1 用户（User）

用户是权限系统里的主体。可以是人，也可以是服务账号、API调用方。

我建议在设计用户模型时，至少包含：

• 用户ID：全局唯一标识
• 身份属性：部门、岗位、职级等
• 认证信息：密码、、证书等

1.3.2 角色（Role）

角色是权限的容器。它把一组权限打包，然后分配给用户。

举个例子：

角色：系统管理员
权限列表：
  - 用户管理：创建、修改、删除、查询
  - 角色管理：创建、修改、删除、查询
  - 日志管理：查看、导出
  - 系统配置：修改

为什么要引入角色？直接给用户分配权限不行吗？

行，但你会后悔。想象一下：公司有500个用户，每个用户都要单独配权限。突然有一天，安全策略变了——所有“运营”岗位的用户都不能删除订单。你要一个一个改吗？

有了角色，你只需要改“运营”这个角色的权限配置，所有拥有该角色的用户自动生效。这就是解耦的力量。

1.3.3 权限（Permission）

权限是最细粒度的操作许可。它通常由两部分组成：

• 资源：要操作的对象（订单、用户、商品）
• 操作：对资源做什么（增、删、改、查）

我习惯用这样的格式来描述权限：

权限标识格式：[资源]:[操作]
示例：
  order:create    → 创建订单
  order:delete    → 删除订单
  user:query      → 查询用户
  report:export   → 导出报表

权限粒度	说明	适用场景
粗粒度	模块级（如“订单管理”）	简单后台、CMS系统
中粒度	功能级（如“订单删除”）	企业管理系统
细粒度	数据级（如“只能删除自己创建的订单”）	金融、医疗等高安全场景

1.4 三要素如何协同工作

咱们用一个真实场景串起来：

1. 用户“张三”登录系统
2. 系统查出张三拥有角色“运营主管”
3. “运营主管”角色包含权限：订单查询、订单修改、报表导出
4. 张三点击“删除订单”按钮 → 系统检查权限 → 发现没有“订单删除”权限 → 拒绝操作

整个过程，用户只关心自己的身份，角色负责承载权限，权限定义具体能做什么。各司其职，清晰明了。

好了，这一节的基础概念就聊到这儿。记住这个三角关系，后面讲RBAC、ABAC、权限继承、数据权限的时候，咱们都会回到这三个核心要素上来。