在 spring boot 应用中，应通过职责分离设计独立的 rest 端点（如 `/resources/my` 和 `/admin/resources/{id}`），而非在 controller 或 service 层内嵌角色分支逻辑，以保障可测试性、可维护性与权限语义清晰性。
当资源访问行为需随用户角色（如普通用户 vs 管理员）发生根本性变化时，最推荐的做法是定义语义明确、职责单一的独立端点，而非在单一路由中根据角色动态切换逻辑。例如：
// ✅ 推荐：面向用户自身资源的端点（无需参数，隐式绑定当前用户）
@GetMapping("/resources/my")
@PreAuthorize("hasRole('USER')")
public ResponseEntity> getMyResources() {
User currentUser = getCurrentUser();
return ResponseEntity.ok(resourceService.findAccessibleBy(currentUser));
}
// ✅ 推荐：面向管理员的全量/跨用户管理端点（显式路径参数 + 强权限约束）
@GetMapping("/admin/resources")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity> getAllResources() {
return ResponseEntity.ok(resourceService.findAll());
}
// ✅ 可选：管理员按用户查询（支持审计或代理操作场景）
@GetMapping("/admin/resources/by-user/{userId}")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity> getResourcesByUserId(@PathVariable Long userId) {
return ResponseEntity.ok(resourceService.findByUserId(userId));
} 这种设计具备三大核心优势：
- 职责清晰，语义自解释：/resources/my 天然表达“当前用户视角”，/admin/resources 明确标识系统管理上下文，避免歧义；
- 权限控制前置且可配置：借助 @PreAuthorize 在方法入口完成声明式鉴权，与业务逻辑解耦，便于统一审计、日志和 RBAC 策略扩展；
- 可测试性与可维护性高：每个端点对应单一行为，单元测试无需模拟不同角色上下文；Service 层方法也保持纯业务语义（如 findAccessibleBy() 专注权限感知查询，而非扮演“路由分发器”）。
⚠️ 需避免的反模式：
- ❌ 在 Controller 中 if (user.isAdmin()) ... else ... —— 混淆请求路由与权限决策，违反单一职责；
- ❌ 在 Service 中封装角色判断逻辑（如 getResourcesByUser(User) 内部分支）—— 导致服务层承担横切关注，难以复用和测试；
- ❌ 仅靠 @PreAuthorize("hasRole('RESOURCES_ALL')") 区分接口但共用同一路径 —— 无法体现资源归属语义，且前端调用易出错。
最后，建议配合 Spring Security 的 MethodSecurityExpressionRoot 自定义权限表达式（如 hasPermission(#userId, 'RESOURCE_READ')），进一步将权限判定下沉至领域模型，实现更细粒度、可插拔的授权体系。
