一、引言从业务痛点看 AOP 权限校验的价值在企业级应用中权限校验是几乎每个接口都绕不开的刚性需求。常见的做法是在每个业务方法开头写上一大段权限判断逻辑GetMapping(/user/delete)publicResultdeleteUser(PathVariableLongid){// 每个方法都要写一遍 —— 重复、冗余、易遗漏LoginUseruserUserContext.getCurrentUser();if(usernull||!user.hasPermission(user:delete)){returnResult.error(403,无权限);}// 真正的业务逻辑...}这种方式的痛点显而易见重复代码每个接口都要写类似的校验模板容易遗漏新增接口时可能忘记加校验造成安全漏洞不易维护权限规则变更时需要逐个修改业务方法耦合度高业务代码中混杂着权限校验逻辑AOP面向切面编程正是解决这类横切关注点Cross-cutting Concerns的标准方案。通过将权限校验抽取为独立的切面我们可以做到✅零业务侵入业务方法只关注核心逻辑✅声明式权限通过注解声明式地配置权限规则✅统一管理所有权限逻辑集中维护✅易于扩展新增校验规则只需修改切面本文将从零开始构建一套基于Spring Boot AOP 注解 JWT的企业级权限校验方案。二、整体设计权限校验的执行流水线2.1 核心流程概览整个权限校验方案遵循「标记 → 拦截 → 解析 → 校验 → 放行/拦截」的执行流水线否是是是否否是否 客户端请求 DispatcherServlet️ 方法是否标注RequiresPermission?⚡ 直接执行业务方法️ AOP 环绕通知拦截 从 UserContext 获取当前用户 是否为超级管理员?⏭️ ignoreSuperAdmin true? 继续校验 角色校验checkRoles 权限码校验checkPermissions✅ 校验通过?❌ 抛出 PermissionException 全局异常处理器 返回统一 403 JSON 返回业务结果2.2 各组件职责处理层上下文层拦截层声明层校验失败RequiresPermission自定义注解PermissionAspectAOP 切面Order 1优先于日志切面UserContextThreadLocal 存储JwtUtilsToken 解析PermissionException自定义异常GlobalExceptionHandler统一异常处理2.3 设计原则原则说明单一职责切面只负责权限校验业务方法只负责业务逻辑开闭原则新增权限规则通过扩展注解属性实现无需修改切面核心逻辑依赖倒置切面依赖 UserContext 抽象不直接依赖具体 Token 解析实现关注点分离通过 AOP 将横切关注点与核心业务逻辑分离2.4 切面使用 Order(1)✅ 校验通过❌ 校验失败 请求️ PermissionAspectOrder(1) LogAspectOrder(2) Controller 全局异常处理器 返回 403关键设计考量权限切面优先于日志切面执行。如果用户无权限请求在权限切面层即被拦截不会进入日志切面和业务方法避免无权限请求污染业务日志不必要的性能开销解析参数、记录日志等