多态本身不直接做鉴权，但通过定义permissionchecker接口及各类角色实现类（如adminchecker、normaluserchecker等），实现权限校验逻辑的统一收口与动态分发，配合工厂或spring注入及aop注解，使新增角色无需修改原有代码。
多态本身不直接做鉴权，但它能帮你把不同角色的权限校验逻辑“统一收口”，让新增角色、调整策略更干净——关键在于用接口定义行为，用子类实现差异。
定义统一鉴权行为接口
先抽象出“我需要校验什么”的能力，而不是写死某个角色怎么判：
- 比如声明一个 PermissionChecker 接口，只含一个方法：
boolean canAccess(String interfaceCode, String userId) - 不关心是管理员、普通用户还是第三方应用，只要实现了这个接口，就承诺能回答“能不能访问”这个问题
- 接口里不暴露数据库查询、角色表关联等细节，只暴露语义明确的行为契约
为每类角色提供具体实现
不同角色的判断逻辑天然不同，用多态自然隔离：
-
AdminChecker：忽略接口白名单，直接返回
true -
NormalUserChecker：查
RoleFunction表，确认该用户所属角色是否绑定过interfaceCode -
ApiAppChecker：验证请求携带的
appid + signature是否合法，再查该应用是否被授权调用该接口 - 后续加新角色（如审计员、试用账号），只需新增一个实现类，不改已有代码
运行时动态选择校验器
怎么知道该用哪个 Checker？靠上下文信息（比如当前用户角色类型）决定：
- 在拦截器或网关层，从 token 或 session 中解析出
roleType（如 "ADMIN"、"USER"、"APP"） - 用简单工厂或 Spring 的
@Qualifier注入对应 Bean：permissionCheckerMap.get(roleType).canAccess(...) - 调用时传的是 PermissionChecker 接口类型，JVM 自动调用实际子类的实现 —— 这就是多态在起作用
配合注解和AOP提升可读性
让权限控制对业务代码透明：
- 自定义注解如
@RequirePermission("user:delete") - AOP 切面在方法执行前，根据注解值 + 当前用户角色，自动选中对应 PermissionChecker 实例执行校验
- 控制器里完全不用写 if-else 判角色，也不用硬编码查表逻辑，职责清晰
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
