Java权限管理采用RBAC模型，通过用户、角色、权限5张表解耦，结合Spring Security注解与动态菜单实现可配置、易扩展的权限控制。
Java中实现用户权限管理，核心是把“谁（用户）能做什么（操作）”这件事结构化、可配置、易扩展。最常用且实用的模型是RBAC（基于角色的访问控制），它不直接给用户赋予权限，而是通过角色作为中间层，解耦用户与权限的关系。
角色与权限的建模设计
在数据库层面，通常需要5张基础表：用户表（user）、角色表（role）、权限表（permission）、用户-角色关联表（user_role）、角色-权限关联表（role_permission）。Java实体类对应时，User和Role用Set集合双向维护关系，避免硬编码权限字符串。
- User类中持有Set roles，标注@ManyToMany映射到user_role表
- Role类中持有Set permissions，同样用@ManyToMany映射到role_permission表
- Permission建议用细粒度定义，如"order:read"、"user:delete:own"，便于后期按HTTP方法+资源+作用域控制
Spring Security集成角色校验
使用Spring Security可快速落地RBAC。关键不是写死if-else判断，而是通过表达式（SpEL）或注解驱动权限检查。
- 在Controller方法上加@PreAuthorize("hasRole('ADMIN')")或@PreAuthorize("hasAuthority('product:edit')")
- 自定义PermissionEvaluator，支持更复杂逻辑，比如判断当前用户是否为该订单的创建者
- 登录成功后，UserDetailsService返回的UserDetails需封装用户全部角色和权限，供SecurityContext使用
动态权限与菜单联动
前端菜单和按钮是否显示，应由后端返回的权限标识驱动，而非前端硬编码。典型做法是登录接口额外返回用户可见的菜单列表（含path、name、icon、permissions等字段）和权限字符串集合。
- 菜单数据可从menu表查询，通过角色-菜单关联表（role_menu）控制可见性
- 权限字符串统一用冒号分隔风格（如sys:user:list），前端路由守卫或指令v-has-perm可据此控制渲染
- 避免在Service层重复查权限，将权限信息缓存到Redis，以用户ID为key，减少DB压力
扩展性与常见避坑点
权限系统上线后常面临多租户、数据级权限、临时授权等需求，初期设计要预留扩展空间。
- 不要把“超级管理员”逻辑写死在代码里，应在角色表中标记is_admin字段，或赋予特殊权限码
- 删除角色时，必须同步清理role_permission和user_role关联数据，否则导致脏权限残留
- 敏感操作（如删库、转账）建议叠加二次验证，不能仅依赖角色判断
- 日志中记录权限拒绝原因（如“缺少order:cancel权限”），方便排查和
审计
权限不是越细越好，而是够用、可维护、易审计。从RBAC起步，再按需引入ABAC（属性基）或数据行级过滤，才是稳健路线。
