应优先使用 early return 替代深层嵌套 if-else，通过提前检查空值、非法状态等失败路径并返回，将主流程保持在最小缩进；分支过多时改用策略模式或 Map 分发。
多重 if-else 容易让逻辑嵌套过深
当连续判断多个条件并分别处理时，if-else if-else 块层层缩进，很快变成“右漂代码”。可读性下降是次要的，真正麻烦的是：新增分支要动上下文、修改某条路径容易漏掉 return 或 break、单元测试覆盖路径变复杂。
常见错误现象：NullPointerException 出现在深层嵌套里，但实际是上层某个 if 没拦住 null；或者改了中间一个 else if，结果后续分支意外执行。
实操建议：
- 每个 guard 条件单独成行，用
if+return提前退出，不套 else - 把“主流程”放在函数最外层缩进最小的位置，而不是最里层
- 对空值、非法状态、权限不足等失败快路径，优先检查并返回
early return 不是 goto，但需要明确返回值语义
早期返回本质是把“异常流”显式提上来，但它不是无脑加 return。Java 里如果方法有返回值，每条 early return 路径都得提供合法值，否则编译失败；若用 void，也要注意是否遗漏了资源清理（比如没关 InputStream）。
立即学习“Java免费学习笔记（深入）”；
使用场景：参数校验、状态前置检查、缓存命中、短路逻辑（如 list == null || list.isEmpty()）。
实操建议：
- 校验类 early return 尽量用
Objects.requireNonNull或StringUtils.isBlank等工具方法，比手写if (x == null)更一致 - 避免在 early return 前做重操作（比如先查数据库再判权限），否则浪费资源
- 如果函数末尾有
finally块或 try-with-resources，early return 不影响其执行 —— 这点常被忽略
else 分支膨胀时，考虑策略模式或 Map 驱动分发
当 if-else 超过 4–5 个分支，且每个分支逻辑较重（比如调不同服务、解析不同协议），硬写 early return 也会难维护。这不是风格问题，是设计信号。
性能影响：纯 if-else 和 early return 在字节码层面差异极小，JIT 优化后基本一致；但 Map 查策略或反射调用会有微小开销，只在高频调用（如每秒万级）才需权衡。
实操建议：
- 分支基于固定字符串或枚举？用
Map<string runnable></string>或switch (enum)（Java 14+ 支持表达式）更清晰 - 分支间有共用初始化或收尾逻辑？抽成模板方法，把差异部分交给子类或 lambda
- 别为了“消灭 else”强行 early return 所有路径 —— 比如两个分支共用同一段日志记录，硬拆反而重复
IDE 和静态检查能帮你发现风格断裂点
IntelliJ 默认会标出“nested if statement”，SpotBugs 有 NS_NON_SHORT_CIRCUIT_BOOLEAN 类似提示，但它们不关心你用不用 early return，只盯结构坏味道。
容易踩的坑：团队里有人习惯 early return，有人坚持单入口单出口，混在一起会导致同一文件出现 if (x) { return; } 和 if (x) { ... } else { ... } 并存，Git diff 看着像两套系统。
实操建议：
- 用
@SuppressWarnings("squid:S1142")（SonarQube 规则）临时压制误报，但别全局关掉 - Code Review 时重点看：guard 条件是否覆盖了所有前置失败可能？return 值是否和方法契约一致？
- 别依赖格式化工具自动转换 ——
if-else转 early return 可能改变空指针行为，必须人工验证
真正难的不是选哪一种，而是同一模块里保持判断粒度一致：什么时候该用 early return 挡掉非法输入，什么时候该用 if-else 表达业务状态互斥。这个边界，文档写不出来，只能靠几次线上问题倒逼出来。
