优化if嵌套的核心是提升可读性与可维护性：①用提前返回替代守门式嵌套；②用卫语句集中前置校验；③将多类型分支拆为策略模式；④对简单判断善用三元运算符和Optional。
if 嵌套过深不是语法错误，但会让逻辑难读、难测、难改，也容易漏掉边界或提前退出。优化目标不是消灭 if，而是让判断更清晰、路径更扁平、责任更单一。
提前返回，砍掉 else 分支
多数深层嵌套源于“满足条件才继续执行”的守门式写法。把否定条件提前处理并返回，主流程自然变直。
- 别这样写：
if (user != null) {
if (user.isActive()) {
if (user.getRole() != null) {
// 主业务逻辑
}
}
}
- 改成这样：
if (user == null) return;
if (!user.isActive()) return;
if (user.getRole() == null) return;
// 主业务逻辑（现在在最外层）
立即学习“Java免费学习笔记（深入）”；
用卫语句（Guard Clauses）集中校验
把所有前置检查（非空、权限、状态、参数合法性）统一提到方法开头，用独立 if + return 或 throw 组织。
- 好处：主逻辑不被干扰，一眼看清“什么情况下不干活”；新增校验项只需加一行，不改动原有结构
- 示例：订单创建前检查
if (order == null) throw new IllegalArgumentException("订单不能为空");
if (order.getItems().isEmpty()) throw new BusinessException("订单不能无商品");
if (!paymentService.isAvailable(order.getPayMethod())) throw new BusinessException("支付方式不可用");
// 后续全是正向流程：扣库存、生成单号、发消息…
拆分逻辑到独立方法或策略
当嵌套里开始出现“根据不同类型做不同事”，说明职责已超载。把分支体抽成小方法，或用策略+Map/枚举驱动。
- 比如根据订单类型走不同审核流，不要写 if-else if … else 套三层，而是：
- 定义接口 OrderApprover，为每种类型实现一个类（PaidOrderApprover、GiftOrderApprover）
- 用 Map<String, OrderApprover> 缓存实例，运行时查表调用：approvers.get(order.getType()).approve(order)
善用 Optional 和三元运算符简化单层判断
对简单赋值或单表达式分支，避免为一行逻辑单独开 if 块。
- 替代 if-else 赋值：
String name = user != null ? user.getName() : "匿名";
- 替代 null 安全调用：
String email = Optional.ofNullable(user).map(User::getEmail).orElse("no-email@example.com");
注意：Optional 不适合用在参数或返回值中滥用，仅用于链式安全取值场景。
