本文探讨在权限控制场景下，应将管理员与普通用户的资源获取逻辑分离到不同 api 端点，而非在 controller 或 service 层动态分支处理，以提升可维护性、可测试性与安全性。
在构建企业级 RESTful 服务时，一个常见需求是：同一类资源（如 Resource）需根据当前用户角色提供差异化视图——管理员可见全部，普通用户仅见其所属或授权范围内的资源。面对这一需求，开发者常陷入“逻辑该放在哪一层”的纠结。本文明确推荐：不应通过条件分支（if (user.isAdmin())）在 Controller 或 Service 中混用行为，而应设计语义清晰、职责分离的独立端点。
✅ 推荐方案：按用例划分端点（RESTful + 职责驱动）
// 普通用户视角：只访问“我的资源”
@GetMapping("/api/resources/my")
@PreAuthorize("hasRole('USER')")
public ResponseEntity<List<Resource>> getMyResources() {
Long userId = getCurrentUserId();
return ResponseEntity.ok(resourceService.findResourcesForUser(userId));
}
// 管理员专属视角：管理所有资源（含路径参数支持细粒度查询）
@GetMapping("/api/admin/resources")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity<List<Resource>> getAllResources() {
return ResponseEntity.ok(resourceService.findAllResources());
}
// （可选）管理员代查某用户资源（审计/支持场景）
@GetMapping("/api/admin/resources/by-user/{userId}")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity<List<Resource>> getResourcesByUserId(@PathVariable Long userId) {
return ResponseEntity.ok(resourceService.findResourcesForUser(userId));
}? 关键设计原则： 端点路径即契约：/my 表达归属关系，/admin/ 明确标识高权限操作域； 权限前置校验：使用 @PreAuthorize 在方法入口拦截，避免无效调用进入业务层； 无运行时角色判断：Service 方法不再接收 User 对象或做 isAdmin() 分支，保持纯业务逻辑。
❌ 为什么不推荐其他方式？
| 方式 | 主要问题 |
|---|---|
| Controller 层分支 | 违反单一职责：Controller 承担了权限决策+路由+业务协调三重责任；难以单元测试（需模拟用户上下文）；违反 REST 原则（同一 URL 返回不同语义数据） |
| Service 层分支 | 业务逻辑污染：getResourcesByUser() 实际承担了“鉴权+查询”双重职责；违反“Service 应专注领域逻辑，不感知认证上下文”的分层约定；导致 Service 难以复用和测试（如离线批量任务无法传入 User） |
| 单端点 + PathVariable 分流 | 混淆资源模型：/resources/{userId} 本应表示“获取指定用户资源”，但对管理员却变成“获取所有资源”，语义失真；且未解决核心问题——权限逻辑仍隐含在实现中 |
✅ 额外收益与最佳实践
- 可观测性提升：日志、监控、API 文档（如 OpenAPI）可精准区分 /my（高频、低风险）与 /admin/（低频、高敏感），便于审计追踪；
- 网关/ACL 配置更简单：Nginx、Spring Cloud Gateway 可直接按 /api/admin/** 做 IP 白名单或速率限制；
- 未来扩展友好：新增角色（如 AUDITOR）只需新增端点 /api/audit/resources，无需修改现有分支逻辑；
- 符合 OAuth2 Scope 设计：可为不同端点分配不同 scope（resources:own vs resources:all），实现精细化授权。
总结
权限不是业务逻辑的开关，而是系统边界的定义者。
将角色差异转化为清晰的端点契约，是比在代码中写 if-else 更健壮、更可持续的设计选择。它让接口意图一目了然，让安全策略显式可配置，也让团队协作成本显著降低——前端知道该调哪个 URL，测试人员知道该覆盖哪些场景，运维人员知道该保护哪条路径。从今天起，请用路径表达权限，而非用 if 掩盖复杂性。
