接口即权限标识，需映射为唯一语义字符串（如user:read），通过Spring Security的@PreAuthorize和authorizeHttpRequests结合实现方法级与路径级鉴权，并在数据库四表中持久化权限关系，支持动态配置与数据级控制。
Java 中接口作为资源访问控制的核心载体，其权限定义需紧扣 RBAC 模型中“谁（用户）通过角色，对什么（接口资源）执行何种操作（权限）”这一逻辑。关键不在接口本身写权限，而在于把接口映射为可识别、可校验、可管理的权限单元。
接口即权限标识：用字符串约定资源+操作粒度
每个受控接口应对应一个唯一、语义清晰的权限字符串，格式通常为 资源:动作，例如：
- user:read —— GET /api/users 或 GET /api/users/{id}
- order:write —— POST /api/orders 或 PUT /api/orders/{id}
- report:export —— GET /api/reports/export
该字符串不依赖 URL 路径硬编码，而是作为权限表（permission）中的一条记录，与角色绑定。这样既支持方法级控制，也便于前端按权限码动态渲染按钮或菜单。
Spring Security 中对接口的权限绑定方式
在 Spring Boot + Spring Security 架构下，接口权限控制主要通过以下两种互补方式落地：
立即学习“Java免费学习笔记（深入）”；
-
@PreAuthorize("hasAuthority('user:delete')")：加在 Controller 方法上，实现方法级鉴权。登录后用户权限已加载进
SecurityContext，运行时自动比对 -
HttpSecurity.authorizeHttpRequests()：在配置类中按请求路径拦截，如
.requestMatchers("/admin/**").hasRole("ADMIN")，适合粗粒度路由保护
二者建议结合使用：路径级规则做第一道防线，方法级注解做精准控制，避免遗漏敏感操作（如导出、批量删除等特殊接口）。
接口权限与数据库权限表的映射关系
权限字符串必须在数据库中有真实落点，典型四表结构支撑该映射：
-
permission表存权限码（perm_code）、描述、所属模块等 -
role_permission表建立角色与权限的多对多关联 - 用户登录时，系统查出其所有角色 → 再查出这些角色拥有的全部
perm_code→ 封装为GrantedAuthority存入上下文 - 每次接口调用，Spring Security 自动从上下文中提取权限码，匹配注解或配置规则
这种设计使权限变更无需改代码——只需后台调整角色-权限关系，重启或刷新缓存即可生效。
注意接口权限的扩展性与边界
纯接口级权限解决的是“能不能调”，但真实业务还需叠加数据级控制：
- 例如
user:read允许访问用户列表，但普通员工只能查自己部门的数据——这需在 Service 层结合用户身份动态拼接 SQL 条件（如 MyBatis 拦截器或自定义注解） - 敏感接口（如密码重置、权限分配）建议额外增加操作审计日志，记录调用者、时间、参数摘要
- 避免将权限码直接暴露给前端用于逻辑判断；前端只负责“隐藏不可见按钮”，后端必须对每个请求做完整权限校验
