权限系统核心是厘清用户、角色、权限、资源四者关系，采用RBAC模型；需建五张基础表，权限码用英文点分命名；Spring Security通过@PreAuthorize和URL拦截实现校验；动态权限靠接口返回菜单，数据级权限需在DAO/Service层自动过滤。
权限系统的核心设计思路
Java权限管理系统本质是解决“谁能在什么条件下访问哪些资源”的问题。关键不在代码多复杂，而在模型是否清晰：用户、角色、权限、资源这四个实体的关系要理顺。常见做法是采用RBAC（基于角色的访问控制）模型，用户通过角色间接获得权限，权限再绑定到具体资源（比如URL、按钮、数据行）。
数据库表结构怎么搭才合理
最少需要五张基础表：用户表（user）、角色表（role）、资源表（resource）、用户-角色关联表（user_role）、角色-权限关联表（role_resource）。资源表建议包含类型字段（如“MENU”、“API”、“BUTTON”），方便后续做细粒度控制。权限码推荐用英文点分命名，例如 user.list、order.delete、report.export.pdf，语义明确也利于前端判断显隐。
Spring Security怎么接入权限校验
用Spring Security最省力。配置类里开启方法级注解支持：@EnableGlobalMethodSecurity(prePostEnabled = true)。在Service或Controller方法上加 @PreAuthorize("hasAuthority('user.edit')") 即可控制调用权。URL层级拦截则在HttpSecurity配置中写死路径规则，例如 .antMatchers("/api/v1/users/**").hasAuthority("user.list")。注意权限校验前必须把当前用户的角色和权限加载进SecurityContext，通常在登录成功后由UserDetailsService完成。
动态权限与数据级控制怎么落地
菜单和按钮显示属于界面级动态权限，可在前端请求 /menus 接口，后端根据当前用户权限返回可访问的菜单树。更难的是数据级权限，比如销售员只能看自己客户的订单。这时不能只靠URL拦截，得在DAO层或Service层加过滤条件。常见做法是用MyBatis的Interceptor或自定义注解，在执行SQL前自动拼接 AND user_id = #{currentUserId} 类似逻辑。也可以用Shiro的 @RequiresPermissions 注解配合自定义Realm做扩展。
立即学习“Java免费学习笔记（深入）”；
