这是我做全栈架构时的一类典型工作:把后端的权限校验,从「散落在每个接口里的 if」收拢成一条声明 + 校验 + 对齐 + 兜底的链路。它体现的是用机制替代人记的工程判断。

权限程序最怕的不是「没做」,而是「散着做」。

「散着做」到底贵在哪

我接手过一个运营后台。权限校验是这种画风:这个接口开头一个 if ),那个接口中间塞一段 if ),还有几个接口压根没校验,靠「前端按钮不显示」硬撑。

老实讲,这种代码最致命的不是「能不能跑」。而是谁都不敢动。一段判断摆在接口里,三个月后你想删它,第一反应不是「这判断对不对」。而是「删了会不会越权」——因为没人知道这段判断是踩了哪个坑加的,删了出了事算谁的。于是它就赖在那儿,越来越多,越来越乱。

再看代价是具体的。

• 谁也不敢删那段判断,因为谁也不知道删了会不会越权。 最终代码里堆满「祖传 if」,谁动谁背锅。
• 前端按钮不显示,不等于后端没校验漏洞。 按钮显示是前端逻辑,接口鉴权是后端职责。黑客根本不经过你的前端,直接打接口。把安全寄托在「按钮藏起来了」,等于没做。
• 几个接口漏校验,纯靠运气没出事。 接口多了之后,「哪个加了哪个没加」全靠人记。今天没出事,是因为没人想到去打那个接口; 明天被人扫到,就是事故，
• 权限和业务逻辑搅在一起,改一个判断得读懂整个方法。 这段判断嵌在业务代码中间,你要重构这个方法。就得先把权限逻辑摘出来——但摘出来的过程中,你怎么知道没摘错?

」。得去翻业务代码才能回答,那就是散着做。

真正该有的状态是,看一眼注解就知道。

注解声明，让权限长在接口上

定义一个注解。大概长这样：

@RequirePermission
@PostMapping
public Result refund {
...
}

注意那个权限 key:"ops:order:refund". 它不是随手写的字符串，而要在迁移脚本的 种子数据 里先注册过。这一条最关键，后面要出事就出在这。

• {程序}:{资源}:{动作},比如 "ops:order:refund" "ops:order:export","fin:bill:audit".规范本身不复杂。但它解决三件事：
• 和和和和和

有了注解。接口要什么权限就是声明出来:

新人不用通读业务逻辑，也能知道 「这个接口吃 ops order refund」。> » > » >> » >> » >>