java权限校验应优先使用if-else而非switch，因支持复杂条件组合且避免npe；推荐用enum替代字符串、封装组合权限为独立方法、分层收敛校验逻辑，并在service层统一处理权限过滤。
Java 条件控制结构是实现权限校验最直接、最可控的底层手段，但用得好不好，关键不在语法本身，而在逻辑组织、空值防御和扩展设计。它不是“if 写多就行”，而是要让每条判断语义清晰、边界明确、易于维护。
优先用 if-else，而不是 switch
权限判断本质是多分支布尔逻辑，而 if-else 天然支持任意复杂条件组合：动态权限码（如 "ORDER:WRITE"）、角色继承（ADMIN 可执行 EDITOR 所有操作）、环境变量（是否在测试环境）等，switch 都难以覆盖。
- Java 14+ 虽支持 switch(String)，但输入必须非 null，否则抛 NPE；而真实场景中用户角色常来自 JWT payload 或数据库字段，可能为 null 或空字符串
- 权限标识若来自配置中心或数据库（如 "REPORT_VIEW_2026"），无法穷举，switch 编译期就失效
- 推荐写法："ADMIN".equals(userRole)（常量在前），既避免 NPE，又防止误用 == 做引用比较
枚举比字符串更安全可靠
用 enum Role { ADMIN, EDITOR, VIEWER } 替代字符串字面量，不只是“看着规范”，而是把错误挡在编译期。
- 拼错角色名（如 "Admiin"）会直接编译失败，而不是上线后静默拒绝或越权
- IDE 自动补全、重构重命名全链路生效，改一个地方就同步所有调用
- 可封装语义方法，比如
role.implies(Role.VIEWER)表达角色继承关系，比一堆 || 更易读 - 反序列化时加
@JsonCreator或 Jackson 枚举配置，确保 JSON 中的 "admin" 能正确转成Role.ADMIN
组合权限必须封装成独立方法
「是管理员或属于当前部门的编辑」这类逻辑，不要写在 Controller 或 Service 方法体里——它既难测试，又无法复用，还容易因短路求值出错。
- 命名体现业务意图，例如
canEditOrder(User user, Order order)，而不是checkPermission(String role, Long deptId) - 方法开头统一判空：
if (user == null || order == null) return false; - 避免嵌套过深：三层以上 if 建议拆出子方法，比如把部门归属校验单独抽成
inSameDepartment(user, order) - 禁止在条件中调用可能为 null 的链式方法，如
user.getPermissions().contains("X")应先判getPermissions() != null
校验位置要分层收敛，不能散落在各处
权限逻辑堆在 Controller 里，等于把安全规则写进胶水代码——改一个权限，要翻十多个接口；加个新角色，得全局搜索 "ADMIN"。
- 小项目可用轻量校验器类，如
PermissionChecker.hasRole(user, Role.ADMIN)，所有入口统一调用 - 中大型项目应走 AOP + 自定义注解（如
@RequireRole(Role.ADMIN)），或 Spring Security 的@PreAuthorize - 注意：Spring Security 的
hasRole("ADMIN")实际匹配的是"ROLE_ADMIN"，要么改数据存 "ROLE_ADMIN"，要么改用hasAuthority("ADMIN") - DAO 层严禁硬编码权限条件（如 MyBatis SQL 里写
AND role = 'ADMIN'），权限过滤必须在 Service 层完成，且数据库查询也要同步加 WHERE 限制，防越权读取
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
