权限校验拦截器应封装用户角色与资源权限匹配逻辑，通过独立PermissionMatcher接口及实现类解耦权限判断，结合自定义注解声明接口权限、缓存角色-权限关系，并支持细粒度数据级校验。
在权限校验拦截器中封装用户角色与资源权限的匹配逻辑，核心是把“谁（用户）能访问什么（资源）”这一判断过程抽离为可复用、易维护、不侵入业务代码的组件。Java 中通常借助 Spring MVC 的 HandlerInterceptor 或 Spring Security 的 Filter/AuthorizationManager 实现，而“封装”体现在将权限匹配逻辑下沉到独立服务或工具类中，避免在拦截器里写 if-else 判断角色字符串或硬编码权限规则。
提取权限匹配职责到独立服务类
不要在拦截器的 preHandle 方法里直接写 if ("ADMIN".equals(role) || hasPermission("user:delete")) 这类逻辑。应定义一个接口和实现，例如：
public interface PermissionMatcher {
boolean hasAccess(Authentication auth, String requestPath, String httpMethod);
}
实现类内部可整合：用户拥有的角色列表、角色对应的权限模板（如从数据库查出 ROLE_ADMIN → [user:read, user:write, user:delete]）、请求路径与权限表达式的映射（如 /api/users/** → user:read），再统一做匹配。这样拦截器只负责调用 permissionMatcher.hasAccess(...)，逻辑清晰、测试友好、支持策略替换（如 RBAC / ABAC）。
使用资源权限元数据统一描述接口权限
避免在拦截器中手动解析 URL 路径匹配权限。推荐为每个 Controller 方法打上自定义注解，声明所需权限：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
@PreAuthorize("hasAuthority('user:write')")
@PostMapping("/users")
public Result createUser(@RequestBody UserDTO dto) { ... }
或更轻量的自定义注解：
@RequirePermission("user:write")
@PostMapping("/users")
public Result createUser(...) { ... }
拦截器通过 HandlerMethod.getMethod().getAnnotation(RequirePermission.class) 获取该接口所需的权限标识，再交由 PermissionMatcher 校验——把“资源需要什么权限”和“用户有没有”彻底解耦。
缓存角色-权限关系，避免重复查库
每次请求都查数据库加载用户角色及对应权限，性能差且易成为瓶颈。应在用户登录成功后，一次性加载其全部有效权限（含角色继承的、直接授予的），序列化后存入 Redis 或本地缓存（如 Caffeine），设置合理过期时间（如 30 分钟）。拦截器校验时直接从缓存取 Set<String> userPermissions，再用 userPermissions.contains(requiredPerm) 判断即可。注意缓存更新时机：用户权限变更时主动清除对应缓存。
支持细粒度资源级校验（可选进阶）
基础角色权限匹配解决的是“能否访问 /users 接口”，但真实场景常需“能否删除 ID=123 的用户”。此时可在拦截器中提取请求参数（如 PathVariable 或 RequestBody 中的 id），传给 PermissionMatcher 的增强方法：
boolean hasAccess(Authentication auth, String path, String method, Map<String, Object> context);
context 可包含资源 ID、所属组织、操作类型等上下文信息，匹配逻辑可结合数据权限规则（如 “仅能管理本部门用户”）动态计算，真正实现“数据级封装”。
