权限校验

这项能力到底在做什么

权限校验，简单说，就是在系统准备把某条数据、某份资料、某个动作交给当前用户之前，先判断这个人到底能不能看、能不能改、能不能执行。

很多企业场景里，真正危险的不是“数据泄露”这四个字本身，而是下面这些很日常的小失控：

不该看的人看到了
该看的人看不到
能看不能改，却被放开了修改
需要审批后才能做的动作，被直接放行了
同一个人换了岗位，权限却没跟着变

权限校验真正解决的，就是把“当前这个人对当前这个对象，当前到底能做什么”先拦住、先讲清楚。

它不是管理制度本身，而是把制度真正落到每一次访问和每一个动作上。

它通常接收什么输入

这项能力接进来的，通常不是一条普通请求，而是一条“某人要访问某对象”的动作请求。

常见输入包括：

查看资料请求
查询数据请求
编辑请求
下载请求
审批请求
删除请求
调用系统接口请求

一起带进来的上下文，常见还有这些：

用户身份
当前角色
所属部门
数据或资料对象编号
动作类型
当前时间
权限规则
审批状态

这些上下文很关键。因为权限不是只看“这个人是谁”，还要同时看：

他现在是什么角色
正在碰什么对象
想做什么动作
当前是否满足额外条件

它能输出什么结果

权限校验最后交出去的，不应该只是“通过”或“拒绝”，而应该是一份可继续执行、可继续追溯的权限判断结果。

常见输出包括：

输出项	说明
校验结果	允许、拒绝、部分允许或需审批
可执行动作	当前能看、能导出、能编辑还是只能部分查看
受限范围	哪些字段、哪些内容需要隐藏或脱敏
规则依据	是哪条权限规则让这次通过或拒绝
审批要求	是否需要额外审批或上级确认
脱敏结果	哪些信息已做隐藏处理
留痕记录	谁在什么时间申请了什么动作、结果是什么

这样下游拿到的，不是一个模糊判断，而是一份清楚说明“能做什么、不能做什么、为什么”的结果。

它在内部是怎么跑起来的

权限校验真正难的地方，不是判断一次通过或拒绝，而是既不能放太开，也不能拦得太死。
它在内部通常会经过下面这条链。

1. 先识别当前是谁在发起请求

系统先确定当前请求来自谁。
这一层通常会读取：

登录身份
当前岗位
所属部门
是否临时代理

2. 再识别这次想做什么动作

同一个人，对同一个对象，不同动作的权限可能完全不同。
所以系统通常会先区分：

是查看
是编辑
是导出
是删除
还是审批、转派、下载

3. 再匹配对象范围和权限规则

权限不是全局一刀切，通常还要看：

当前对象属于哪个部门
是不是当前项目、当前客户、当前批次
是否包含敏感字段
是否只允许部分岗位访问

4. 再判断是否需要额外条件

有些动作不是完全禁止，而是需要满足额外条件。
比如：

需要审批通过
只能在特定时间段执行
只能由上级角色操作
需要二次确认

5. 再决定放行、拒绝、脱敏或转审批

到了这一步，系统才会真正输出动作结果。
常见情况包括：

直接放行
拒绝访问
允许部分查看
先脱敏再展示
转人工审批

6. 最后把判断过程完整留下来

权限能力值不值得信，不只是它拦住了什么，还要看后面能不能说清：

谁来过
想做什么
为什么被允许或被拒绝
有没有走审批

权限校验的详细内部流程图

flowchart TB
    A[输入访问或操作请求] --> B[识别用户身份、角色、部门和代理状态]
    B --> C[识别当前对象和动作类型]
    C --> D[匹配对象范围、敏感级别和权限规则]
    D --> E[检查是否需要审批、二次确认或额外条件]
    E --> F{当前是否满足执行条件?}
    F -->|否| G[拒绝访问或转人工审批]
    F -->|是| H[判断是否需要脱敏或部分放行]
    H --> I{是否需要脱敏?}
    I -->|是| J[输出脱敏后的可见结果]
    I -->|否| K[直接放行对应动作]
    G --> L[记录拒绝原因和留痕]
    J --> M[记录规则依据、审批状态和留痕]
    K --> M
    L --> N[交给审计、复盘、异常处理继续使用]
    M --> N

它最后会把什么交给下游流程

权限校验真正交给下游的，不只是一个开关结果，而是一份完整的访问判断结果。

常见会交出去这些内容：

这次是否允许
允许做哪些动作
哪些字段需要隐藏
是否需要审批
命中了哪条规则
这次请求的过程留痕

这样后面的流程才能继续做：

资料展示
数据查询
工单处理
审批流转
审计复盘
异常排查

它怎么接入业务才真正有价值

权限校验最怕的，不是拦不住，而是规则太粗，最后不是放太开，就是拦太死。

真正常见、也最有价值的接法，一般有下面几种：

1. 接在知识问答和检索前面

先判断当前用户能看哪些资料，再返回答案。
这样同一个系统就能服务不同岗位，而不会把全部信息一起摊开。

2. 接在敏感数据查询前面

只要涉及客户信息、医疗记录、金融资料、经营数据，权限校验就应该先行。
这样后面的动作才稳。

3. 接在编辑和审批动作前面

很多问题不是看错，而是改错。
权限校验先把动作边界定住，后面的系统才不会被误操作带偏。

4. 接在跨系统流转前面

如果一个动作要调用多个系统，权限校验可以先决定当前请求到底有没有资格往下走。
这会明显减少后面反复打回。

什么情况下必须转人工

权限校验虽然很适合自动化，但下面这些情况最好让人工接手：

当前用户身份异常或角色不明
一条请求同时命中多条冲突规则
权限边界刚调整，规则还没稳定
当前动作涉及高风险数据或关键业务结果
需要临时授权、代理授权或跨部门授权
对象敏感级别和用户范围存在冲突
当前请求疑似异常访问
规则和现实组织关系不同步

真正稳的企业做法，不是让系统一刀切地全拦或全放，而是让它先处理大部分标准权限，把例外授权和高风险请求交给人确认。

为什么这项能力站得住

权限校验之所以在企业里很有价值，是因为很多流程问题最后都不是“系统会不会做”，而是“系统该不该让这个人做”。

1. 它解决的是“边界不清”

只要数据、资料、动作有边界，权限校验就是那道最前面的门。
门不稳，后面很多流程都会出问题。

2. 它特别适合角色多、数据敏感的场景

岗位越多、资料越敏感、动作越复杂，权限校验的价值越明显。

3. 它能把制度和系统真正接起来

制度说“谁能看、谁能做”，权限校验负责把这件事真正落到系统每一次动作上。
这就是它的核心价值。

4. 它边界清楚，所以更容易落地

标准权限自动判断，例外情况人工审批。
这种接法既稳，也容易被组织接受。