应警觉并避免 if-else 嵌套超过 2 层，因其混杂控制流、业务判断与副作用，导致可读性差、易出错、难测试；推荐用提前返回、optional（适度）、策略映射和 ide 检查约束。
Java if-else 嵌套超过 3 层就该警觉了
不是语法报错，但实际项目里嵌套 4 层以上 if-else 几乎必然带来维护灾难：改一个分支要盯五分钟逻辑，加个新条件容易漏掉某个 else if 的边界，单元测试覆盖率也难拉高。
根本原因不是“嵌套本身错”，而是它把**控制流、业务判断、副作用操作全搅在一起**。比如下面这种典型写法：
if (user != null) {
if (user.isActive()) {
if (user.getRole() != null) {
if ("ADMIN".equals(user.getRole().getName())) {
// do something
}
}
}
}
- 每层
if都在做不同维度的检查（非空、状态、角色存在、角色名），混着写就分不清主次 -
user.getRole().getName()可能抛NullPointerException，但错误堆栈看不出是哪层空指针 - 想给“非 ADMIN 用户”加日志？得在四个
else分支里重复写，或提成方法——那不如一开始就不嵌套
用 Optional + 提前返回替代深层嵌套
Java 8+ 的 Optional 不是用来包住所有变量的，而是帮你把“检查失败就退出”这个动作显式化。重点不是链式调用多酷，而是让正常路径保持左对齐、一眼可见。
上面的例子可改成：
if (user == null) return; if (!user.isActive()) return; if (user.getRole() == null) return; if (!"ADMIN".equals(user.getRole().getName())) return; // do something —— 这里就是干净的 happy path
- 每个守卫条件都独立、可读、可单独测试
- 不需要额外括号或缩进，IDE 也能正确高亮执行路径
- 如果必须返回值，用
return Result.error("xxx")比throw new XxxException()更可控（避免被上层try-catch吞掉） - 别硬套
Optional.ofNullable(user).filter(...).map(...)——链太长一样难 debug，且map里抛异常会变成NoSuchElementException，语义失真
当判断逻辑有多个正交维度时，用策略模式或 Map
比如用户权限校验要同时看：租户类型（public/private）、资源所属部门（own/other）、操作类型（read/write/delete）。三个维度组合起来有 2×2×3=12 种情况，硬写 if-else if 会疯。
更稳的做法是把判断条件提取成 key，行为绑定到函数：
Map<string runnable> handlerMap = Map.of(
"public_read", () -> handlePublicRead(),
"private_write", () -> handlePrivateWrite(),
// ...
);
String key = tenantType + "_" + operation;
Runnable handler = handlerMap.get(key);
if (handler != null) {
handler.run();
} else {
throw new UnsupportedOperationException("No handler for " + key);
}</string>
- 新增一种组合？只加一行
Map初始化，不碰原有分支逻辑 - key 构造方式要稳定：
Objects.hash(tenantType, dept, operation)比字符串拼接更安全，但调试时不如字符串直观 - 别用
ConcurrentHashMap存这种静态映射——初始化后不会变，徒增内存开销和锁开销 - 如果 handler 之间共享状态（比如要累积日志），就别用 lambda，改用私有方法引用，避免闭包捕获混乱
IntelliJ 警告不是摆设：用 Inspection 真实约束嵌套深度
IDEA 默认的 Boolean expression complexity 和 Nested if statements 检查，建议把阈值设成 2（即最多允许 1 层嵌套）。这不是教条，而是卡住“下意识缩进”的惯性。
- 设置路径：
Settings → Editor → Inspections → Java → Control flow issues → Nested if statements，把Report nested if statements deeper than改成2 - 生效后，像
if (a) { if (b) { if (c) { ... } } }会被标黄，点灯泡就能一键转成提前返回 - 团队共用
codeStyle.xml时，把这个 Inspection 加进Inspection profile，CI 阶段用inspectCode扫描，比 Code Review 早发现问题 - 注意：
switch表达式（Java 14+）不算嵌套，但它内部的case如果又带if，照样触发警告——别以为换了语法就能绕过逻辑复杂度
嵌套本身不难写，难的是半年后你还记得第三层 else 里那个 user.getProfile().getSettings() 是不是可能为 null。把“可能为空”“状态不符”“权限不足”这些信号从缩进里解放出来，才是重构真正的落点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
