核心是理清User、Role、Permission三者关系：User一对多关联Role，Role持有permissionCode字符串集合，Permission用枚举管理；权限校验统一入口，封装PermissionChecker工具类，避免硬编码if-else和分层混乱。
Java里做用户权限管理，不靠框架也能跑起来，但直接手写容易掉进“权限判断散落各处”“角色和资源耦合太紧”“没考虑权限缓存导致反复查库”这些坑。核心不是堆代码，而是把 User、Role、Permission 三者关系理清，并让检查逻辑可复用、可扩展。
如何设计基础权限模型类（不依赖Spring Security）
手写权限系统，先稳住数据结构。别一上来就写拦截器或注解，先把实体和关系定下来：
-
User持有roleId或roleList（一对多更灵活，支持用户多角色） -
Role关联一组permissionCode字符串（如"user:read"、"order:delete"），不建议直接存 SQL 权限语句 -
Permission类可省略，用字符串常量或枚举管理权限码，例如public enum PermissionCode { USER_READ("user:read"), ORDER_WRITE("order:write") } - 关键：权限检查方法应统一入口，比如
permissionService.hasPermission(userId, "user:edit")，内部查库或查缓存，外部不感知细节
如何实现运行时权限校验（避免硬编码if-else）
每次接口都写 if (!hasPermission("xxx")) throw new AccessDeniedException() 是反模式。推荐封装成工具方法或轻量注解 + AOP（不用 Spring 也能用 Java Agent 或手动代理，但小项目用静态方法更直接）：
- 定义校验工具类
PermissionChecker，提供require(String permissionCode)和check(String permissionCode): boolean两种风格 - 在 Service 方法开头调用
PermissionChecker.require("product:update")，失败抛SecurityException，由全局异常处理器转 HTTP 403 - 避免在 Controller 层做权限判断——那里只管参数解析和响应包装；也不要在 DAO 层加权限过滤（违反单一职责）
- 注意：校验前必须确保
userId已从 Session / Token 中可靠提取，别用前端传来的userId做权限依据
继承与封装怎么用在权限模块中（别为了OOP而OOP）
权限本身不是靠继承来扩展的，强行让 AdminUser extends User、GuestUser extends User 只会让权限逻辑分散到子类里，后期难维护。真正该封装的是行为：
立即学习“Java免费学习笔记（深入）”；
- 把“获取当前用户所有权限码”的逻辑封装进
UserPermissionLoader，它可从 DB 查、从 Redis 加载、甚至合并多个来源（如部门权限 + 角色权限） - 把“URL 路径匹配权限码”的规则封装进
AntPathMatcherPermissionResolver，支持类似/api/v1/users/** → user:read的映射，而不是每个 Controller 写一堆if (path.startsWith("/users")) - 如果真要用继承，仅限于策略场景：比如
DbPermissionChecker和CacheFirstPermissionChecker都继承PermissionChecker抽象类，共享preCheck()和postCheck()钩子
最易被忽略的一点：权限变更后，旧的权限缓存没失效。哪怕你用了 ConcurrentHashMap 存用户权限，用户在后台改了角色，下次请求还是用的老快照。要么加主动清除逻辑（改角色时发事件清缓存），要么设短过期时间（如 60 秒），别默认“查一次永久有效”。
