if else 是好代码吗？从分支本质到工程实践的全面拆解

说个最近让我印象特别深的事。有次 code review，一个同事提交了二十多行 if else 逻辑，另一个同事直接在评论区写了句："这种代码就别提了，重构一下。"我当时还挺纠结的——这段代码确实不算优雅，但业务逻辑本来就是按条件分派的，不用 if else 还能用什么？

后来我仔细想了想，"if else 是不是好代码"这个问题，压根就不能用"是"或者"不是"来回答。它在不同场景、不同约束、不同抽象层级下，答案完全不一样。早年写单片机程序，if else 用得飞起，一点问题没有；后来写中后台业务系统，if else 堆多了，改一个需求能把人逼疯。所以与其争论"if else 好不好"，不如搞清楚：什么时候该用它，什么时候该换一种表达方式。

这篇文章我就想把自己在这些年实战里对 if else 的理解、踩过的坑、还有各种替代方案的适用场景，一次性聊透。适合正处在"刚写完一堆 if else 被 review 打回来"阶段的同学，也适合团队里正在定编码规范的人。

1. 条件判断的本质：为什么我们会写出 if else

在聊"好不好"之前，得先弄清楚 if else 到底解决什么问题。本质上，它是在表达一种映射关系：输入满足某个条件，就走某条路径。这是计算机科学里最底层的分支结构，从汇编时代的 JMP、JE、JNE 指令一路演化过来，高级语言把它包装成了 if、switch、三元表达式这些更容易读的形式。

1.1 分支的起源与 CPU 的视角

从汇编的角度看，if else 最终会被编译成条件跳转指令。CPU 执行时有个分支预测器，它会根据历史规律猜测下一次跳转到哪里。如果预测正确，流水线不中断，性能很好；如果预测错误，流水线要清空重来，代价很大。

这也是为什么有些高性能代码里，作者会用各种技巧避免分支。比如在图像处理、加密算法这些场景，一条 cmov 条件移动指令可能就替代了分支跳转。但在普通业务代码里，这个层面的性能差异几乎可以忽略不计。我见过有人为了"优化"把业务代码里的 if else 全改成位运算，结果可读性差了十倍，性能提升可以忽略不计，这纯属捡了芝麻丢西瓜。

所以在业务系统里讨论 if else，我们讨论的核心不是 CPU 层面的性能，而是代码的可读性、可维护性和可扩展性。这是个非常关键的定位，后面所有分析都建立在这个基础上。

1.2 程序员视角的"分支"复杂度

如果只写一两层 if else，任何正常人读起来都没问题。代码复杂度是随着分支深度和分支数量非线性增长的。

比如下面这段逻辑：

java复制if (order != null) {
    if (order.getStatus() == PAID) {
        if (order.getPayment() != null) {
            if (order.getPayment().getChannel() == WECHAT) {
                // 微信支付已付款订单的处理
            }
        }
    }
}

这是典型的箭头型代码，一层套一层，四个条件缩进四次。读代码的人需要同时维护四个条件状态，大脑工作记忆很容易溢出。更麻烦的是，当产品经理说"加一个支付宝渠道"的时候，你需要在最内层再塞一个分支，或者在最外层再套一个判断。

这种嵌套结构，才是 if else 被诟病为"坏代码"的真正原因。它不是 if else 本身的错，而是我们使用它的方式有问题——把多维条件全部揉在一块，形成了一张无法解开的条件网。

理解了这个本质，后面所有讨论都有了解释：工具没有好坏，用法有好坏。

2. 批评 if else 的三个典型理由，以及我的看法

社区里对 if else 的批评主要集中在三块：嵌套地狱、违背开闭原则、难测试。我一个个拆开讲，每个批评背后都有真实案例支撑。

2.1 嵌套地狱与可读性崩溃

先看嵌套的问题。我接手过一个老系统的代码，里面有个方法计算运费，if else 嵌套最高到了七层，加上 for 循环和 try-catch，整个方法将近三百行。每次改动都小心翼翼，因为牵一发而动全身。

这种代码最大的问题是"信息熵"太高。读者要把每一层的条件放进工作记忆，一层一层推理才能走到最终逻辑。人的短期记忆容量大概只有四五个组块，超过这个量级必然出错。我经常打一个比方：读这种代码，就像在一个没有灯光的仓库里找一颗钉子，你可能知道它在某个角落，但每次寻找都要翻开成堆的箱子。

嵌套不是 if else 天然带来的，而是缺少提前返回、缺少卫语句导致的。

2.2 违背开闭原则之后的连锁反应

面向对象设计里有个开闭原则：对扩展开放，对修改关闭。一堆 if else 极易违反这个原则。每次新增条件，都得找到原来的方法，在原来的逻辑里插入新分支。改着改着，可能影响已有分支，引发回归。

有个很典型的场景，就是多支付渠道的订单处理。最初只有微信支付，写一个 if 判断;后来加了支付宝，再加一个 else if；再后来加了银联、花呗、银行卡……每加一个渠道，方法就要被修改一次，而且分支之间的执行顺序还可能有依赖。这就是典型的"应该用多态或者策略模式"的信号。

2.3 可测试性为什么跟着变差

if else 结构的测试难点，在于分支组合数爆炸。假设一个方法里有三个独立条件，每个条件两种取值，组合起来就是 8 种场景。如果有五个条件，就是 32 种。为了测试覆盖率，你可能会写几十个测试用例，里面大量重复的设置代码，只在某个条件上做变化。

我在实际项目里见过因为 if else 膨胀导致单测代码量超过业务代码十倍的情况。而当重构为策略模式或者表驱动之后，每个分支变成独立的类或数据项，测试就变成了"对每个策略单独测试"，用例数量和复杂度都会明显下降。

但这里我必须说一句公道话：这些批评针对的是"滥用" if else，而不是所有条件判断。在很多简单场景里，用 if else 反而是最简单直接、最容易理解的方案。批评者经常会犯一个错——拿着大项目的复杂场景去要求所有小场景都上设计模式，导致过度设计。

3. 替代 if else 的几种主流思路，以及各自的适用边界

说完了问题，来讲解决方案。我按"侵入性从低到高"排序，介绍四种替代方案：卫语句、表驱动、多态/策略模式、状态机。每种都会讲清楚适用场景，以及不适合的场景。

3.1 最容易被忽视的利器：卫语句

卫语句（guard clause）其实是 if 的一种变形，但它能彻底解决嵌套问题。核心思想是：先把所有异常、前置条件、不满足的情况挡在方法开头，然后主逻辑一路顺下来。

比如前面那个订单判断，用卫语句重构后变成：

java复制public void handleOrder(Order order) {
    if (order == null) {
        return;
    }
    if (order.getStatus() != PAID) {
        return;
    }
    if (order.getPayment() == null) {
        return;
    }
    String channel = order.getPayment().getChannel();
    // 主逻辑
}

这么一改，嵌套彻底消失了。所有"条件不满足就退出"的情况都提前处理掉，主逻辑从"在层层条件中寻找"变成"顺畅地从上往下读"。

卫语句的适用场景特别广，几乎所有业务代码都能用上。它是成本最低、收益最明显的重构方式。我见过不少团队把"先写卫语句，再写主逻辑"作为代码规范写进 CI 检查里。它并不消灭 if，但它消灭了"嵌套"这种最大的可读性杀手。

3.2 表驱动：把代码逻辑变成数据查找

当条件分支不是"复杂逻辑"而是"根据输入返回特定值"时，表驱动是最好的方案。思路非常简单：用 Map、数组或者数据库表，把条件映射到结果，代码里只查表。

我之前写过一个订单状态翻译的功能。最初是这样的：

java复制public String getStatusText(String status) {
    if ("CREATED".equals(status)) {
        return "已创建";
    } else if ("PAID".equals(status)) {
        return "已付款";
    } else if ("SHIPPED".equals(status)) {
        return "已发货";
    } else if ("COMPLETED".equals(status)) {
        return "已完成";
    } else if ("CANCELLED".equals(status)) {
        return "已取消";
    }
    return "未知";
}

用表驱动重构之后，简化为：

java复制private static final Map<String, String> STATUS_TEXT = Map.of(
    "CREATED", "已创建",
    "PAID", "已付款",
    "SHIPPED", "已发货",
    "COMPLETED", "已完成",
    "CANCELLED", "已取消"
);

public String getStatusText(String status) {
    return STATUS_TEXT.getOrDefault(status, "未知");
}

这个方案的巨大优势在于：新增状态时，业务代码一行不用改，只改数据。数据与逻辑分离之后，甚至可以让非技术人员来维护映射关系。在高性能场景下，HashMap 查找是 O(1) 的，比一串 if else 的 O(n) 更优。

需要注意的边界：表驱动只适合"条件→结果"的映射。如果不同分支下执行的是完全不同的算法，就不适合硬塞进表里。

3.3 多态与策略模式：处理真正复杂的业务分派

当分支里面不是简单返回值，而是整段不同的业务逻辑时，就该考虑策略模式了。它的核心思想是把每个分支变成独立的类，通过一个统一的接口来调用，调用方完全不需要知道具体逻辑。

比如运费计算。假设有三种快递公司，每个公司的计费规则不同：

java复制public interface ShippingStrategy {
    double calculate(Order order);
}

public class SFStrategy implements ShippingStrategy {
    public double calculate(Order order) {
        // 顺丰逻辑
    }
}

public class YTOStrategy implements ShippingStrategy {
    public double calculate(Order order) {
        // 圆通逻辑
    }
}

public class ZTOStrategy implements ShippingStrategy {
    public double calculate(Order order) {
        // 中通逻辑
    }
}

然后在工厂里根据公司名选择策略：

java复制public class ShippingStrategyFactory {
    private static final Map<String, ShippingStrategy> STRATEGIES = Map.of(
        "SF", new SFStrategy(),
        "YTO", new YTOStrategy(),
        "ZTO", new ZTOStrategy()
    );

    public static ShippingStrategy getStrategy(String company) {
        return STRATEGIES.get(company);
    }
}

我特意把策略注册和表驱动结合起来，因为实际项目里经常是这种组合打法。新增物流公司时，只需要新增一个策略类并在 Map 里注册，完全不需要修改调用方。

但策略模式也有代价：类数量增多。如果业务只有两三个分支，且逻辑简单，强行上策略模式反而显得过度设计。我会在后面的章节说明怎么判断这个度。

3.4 状态机范式：解决状态流转的混乱

有时候条件判断的核心不是"选哪个分支"，而是"状态怎么流转"。比如订单状态从 CREATED 到 PAID 再到 SHIPPED，中间有各种校验和动作。用 if else 写状态流转，会非常痛苦。

这类场景适合用状态机。Java 有 Spring StateMachine，Python 有 transitions 库。定义状态和事件，整个流转就变成了一张表：

java复制builder.configureStates()
    .withStates()
        .initial("CREATED")
        .state("PAID")
        .state("SHIPPED")
        .end("COMPLETED");

builder.configureTransitions()
    .withExternal()
        .source("CREATED").target("PAID").event(PAY)
        .source("PAID").target("SHIPPED").event(SHIP)
        .source("SHIPPED").target("COMPLETED").event(COMPLETE);

状态机最大的价值是，把状态流转的合法性集中管理。不可能有"从 CREATED 直接跳到 COMPLETED"这种非法路径，因为配置里根本没有这条边。如果用 if else 写，你得在每一层判断当前状态，很容易漏掉某个组合。

我接触过的几个项目里，状态机一旦落地，状态相关的 bug 明显减少——因为非法流转在架构层面就被拦住了。但它也有学习成本，团队里至少得有一个人能吃透状态机的概念，否则后期维护容易变成黑盒。

4. 复杂场景下的 if else：异步编程、安全规范与 AI 生成代码

聊完了基础的重构方案，来点更贴合当前技术热点的内容。现在的前端后端项目里，异步编程几乎无处不在，AI 编程工具也逐步进入日常开发。这些场景下，if else 的表现又不一样。

4.1 异步编程里的条件判断陷阱，以 CompletableFuture 为例

Java 的 CompletableFuture 做异步编排时，条件判断通常出现在回调函数和异常处理里。很多人会写出这样的代码：

java复制CompletableFuture<Order> future = CompletableFuture.supplyAsync(() -> loadOrder(orderId));

future.thenApply(order -> {
    if (order == null) {
        throw new OrderNotFoundException("订单不存在");
    }
    if (!order.isPaid()) {
        throw new OrderNotPaidException("订单未支付");
    }
    return order;
}).exceptionally(ex -> {
    if (ex instanceof OrderNotFoundException) {
        return defaultOrder();
    } else if (ex instanceof OrderNotPaidException) {
        return waitingOrder();
    } else {
        return null;
    }
});

这里有一个非常隐蔽的坑：异常链在 exceptionally 里会被包装成 CompletionException，直接 instanceof 判断经常会失效。正确做法是用 getCause() 把底层异常掏出来再判断。

异步编程里的条件判断，我非常建议把条件分支尽量封装成小的函数，而不是在回调链里堆 if else。在嵌套回调里使用 if else，处理不当很容易出现条件漏判或者异常吞噬。CompletableFuture 的链式调用每一个环节都可能产生异常，异常分支本身就是一个隐形条件，把所有环节的条件堆在一起，会显著提高出 bug 的概率。

4.2 安全编码规范视角：MISRA C 里对 if else 的要求

热搜词里有个"if必须以else结尾在misra里有吗"，这个问题透露了一个关键技术点：安全关键系统领域的编码规范，确实对条件分支有严格约束。

MISRA C 是最著名的汽车嵌入式行业安全编码标准。里面有一条规则和 if 相关：if、else if、while、for 等控制表达式必须显式使用布尔变量，不能依赖隐式类型转换。同时还有"规则 15.7"要求：所有 if...else if 链必须以 else 子句结束，即使这个 else 里什么都不做，也要留个注释说明"没有其他情况"。

这条规则的出发点不是代码美学，而是安全性。当一个 else if 链没有 else 子句时，如果未来某个未预料到的条件出现，代码会静默地什么都不执行，这可能造成严重后果。比如在汽车刹车系统里，某个传感器状态不匹配时，没有兜底逻辑可能导致刹车失效。

这类编码规范对分支的约束，反映了一种价值观：在安全关键系统中，可预测性优先于简洁性。如果你在普通 Web 项目里也用"必须 else 结尾"这种风格，我会觉得冗余；但如果做嵌入式、汽车电子、医疗器械相关开发，这条规则建议严格执行。

4.3 AI 编程工具会改变 if else 的写法吗

现在 Cursor、GitHub Copilot、Claude Code 这些 AI 编程助手已经非常普及了。很多人关心 AI 生成代码里的 if else 质量。我的实测感受是：AI 生成的代码风格，高度依赖训练数据里主流代码的写法。

如果你给 Cursor 一个清晰的任务描述，比如"根据订单状态返回对应文本"，它大概率会生成一个 switch 表达式或者 Map 映射，因为 GitHub 上高质量代码大量使用这种方式。但如果提示词里写的是"处理订单的各种情况"，没有给出具体结构要求，AI 可能会生成一大串 if else 嵌套。

这给我们一个启发：AI 编程时代，人的判断力更重要了。AI 负责快速生成，我们负责 review 结构。如果你的团队有 if else 使用规范，最好直接在提示词里告诉 AI："不要嵌套超过两层""优先使用卫语句""把分支逻辑抽成独立方法"，这样生成的代码更接近团队风格。

我最近在做的事情，是把自己总结的代码风格规范写成一份 CODING_STYLE.md，然后在 Cursor 的规则文件里引用它。效果立竿见影，生成的 if else 嵌套少了很多。工具在进化，但判断标准没有变：可读性、可维护性依然是第一优先级。

5. 实战复盘：一段烂代码的完整重构过程

纸上谈兵聊得再多，不如直接看一个完整案例。下面这段代码，是我从真实项目里拿过来的，只改了变量名和注释。我会带着你一步一步走完整个重构过程。

5.1 原始代码：业务里最常见的 if else 堆积

python复制def calculate_discount(user, order):
    discount = 0.0
    if user is not None:
        if user.is_vip:
            if order.total >= 500:
                if user.level == 1:
                    discount = order.total * 0.2
                elif user.level == 2:
                    discount = order.total * 0.3
                else:
                    discount = order.total * 0.25
            else:
                if user.level == 1:
                    discount = order.total * 0.1
                elif user.level == 2:
                    discount = order.total * 0.15
                else:
                    discount = order.total * 0.12
        else:
            if order.total >= 500:
                discount = order.total * 0.05
            else:
                discount = 0
    else:
        discount = 0
    return discount

这段代码的槽点很密集：嵌套了四层；用户等级逻辑在每个分支里重复出现；else 分支全是无效赋值；如果将来要加一个"新人专享折扣"或者"季节大促折扣"，修改起来非常痛苦。

5.2 第一轮重构：引入卫语句和中间映射

先把没有意义的嵌套拆掉，同时抽掉 user 为空的场景：

python复制def calculate_discount(user, order):
    if user is None or order is None:
        return 0.0
    
    if not user.is_vip:
        return discount_for_normal(order)
    
    return discount_for_vip(user, order)

把用户等级和金额档位的计算逻辑拆到独立函数里：

python复制def discount_for_vip(user, order):
    level_rate = {
        1: 0.1,
        2: 0.15,
        3: 0.12,
    }.get(user.level, 0.1)
    
    if order.total >= 500:
        level_rate *= 2  # 满500翻倍
    
    return order.total * level_rate

这一步已经把嵌套清理干净了。用户等级映射变成了一张表，将来加等级只需要改字典，不用动代码结构。

5.3 第二轮重构：引入策略，为扩展做准备

如果业务确定以后会有更多折扣类型，比如"新人折扣""节日折扣""渠道专享折扣"，那可以把折扣计算抽象成策略：

python复制class DiscountCalculator:
    def calculate(self, user, order):
        raise NotImplementedError

class VipDiscount(DiscountCalculator):
    def calculate(self, user, order):
        level_rate = {1: 0.1, 2: 0.15, 3: 0.12}.get(user.level, 0.1)
        if order.total >= 500:
            level_rate *= 2
        return order.total * level_rate

class NormalDiscount(DiscountCalculator):
    def calculate(self, user, order):
        if order.total >= 500:
            return order.total * 0.05
        return 0.0

class DiscountFactory:
    @staticmethod
    def get(user, order):
        if user is None or order is None:
            return NullDiscount()
        if user.is_vip:
            return VipDiscount()
        return NormalDiscount()

这个版本的核心变化在于：主流程从"判断怎么算"变成了"拿到一个能算的对象"，然后调用 calculate。未来新增折扣类型时，主流程完全不改动，只要新增一个类并在工厂里注册即可。

5.4 每一轮重构背后的决策逻辑

第一轮卫语句的目的是"止血"，让代码能读；第二轮引入策略的目的是"规划扩展"，让代码好改。两轮重构的节奏不能反过来——如果代码还在嵌套地狱里，直接上策略模式，只会得到一个"类特别多但每个类里还是嵌套"的结果。

重构的每一步都要有自动化测试保护着。我会给原始代码先写测试，把已知的行为全部锁死。每重构一步，跑一次测试，确认行为没有变化。等整个重构完成后，再根据新结构补充针对性的测试用例。没有测试保护就大规模重构，基本等于在雷区里裸奔。

我也踩过类似的坑：有次重构到一半，测试一跑发现某个边缘场景的行为被我"优化"了，结果产品经理说那个"不符合逻辑"的行为其实是个隐藏需求。从那以后我养成了一个习惯：重构之前，先问产品"这个分支当初为什么加"。很多时候，代码里的每个 if 都代表一段业务故事，不能粗暴删掉。

6. 什么时候应该坚持用 if else：拒绝过度设计

刚才聊了很多替代方案，现在我得反过来泼一点冷水。if else 不是洪水猛兽，很多场景下它就是最佳答案。判断的标准其实很朴素：代码的复杂度和业务的复杂度要匹配。

6.1 判断标准：复杂度守恒定律

我提出一个"复杂度守恒"的观点：产品的业务复杂度是客观存在的，不会被设计模式消灭，只能被转移。策略模式没有消灭"有六种运费规则"这个事实，只是把它分散到了六个类里。如果六种规则本身的逻辑都很简单，硬拆六个类，反而是把简单问题复杂化。

所以我的判断标准是三条：

• 分支逻辑是否简单直接，一眼能看懂？如果是，就用 if else。
• 分支数量是否会快速增长？如果超过 3-5 个且每周都在增加，考虑策略模式或表驱动。
• 每个分支内部是否有独立的、较复杂的逻辑？如果每个分支只有一两行，用 if else 完全没问题。

有一个实际的项目例子：一个数据校验方法，最初只有"非空"和"长度"两个判断，用 if else 写了十行。后来加了格式、范围、关联字段等条件，方法膨胀到两百多行。这就是典型的"从 if else 升级为规则引擎"的时机。但如果只写了一两个判断，就急着上规则引擎，那叫炫技。

6.2 性能敏感场景下的合理放行

在性能敏感的场景，比如游戏引擎、图像处理、高频交易系统，if else 可能反而是最优选择。

现代 CPU 分支预测器对"规律性很强的分支"预测准确率极高。如果条件是"90% 的情况走同一个分支"，分支预测几乎不失误，性能损失极小。策略模式涉及虚函数调用，有时会阻碍内联优化，在某些场景下性能反而不如直接 if else。

我在做图像处理的小工具时，处理每个像素都要判断颜色空间，用 if else 直接写，性能很好。如果为了"优雅"搞多态调用，反而可能因为虚函数调用和分支跳转导致性能下降。所以，这个场景下，if else 就是最合理的代码。

6.3 什么时候"直接写"比"抽象"更重要

我见过很多团队"过度抽象"到让人崩溃的代码。一个只有三种类型、总共五十行的对象转换逻辑，硬设计了抽象基类、工厂、依赖注入，牵连七八个文件。每看一次调用链，都要翻阅五个类。这比 if else 糟糕多了。

代码的读者是人，不是编译器。编译器和 IDE 最喜欢结构标准化的代码，但人也需要直觉上的流畅性。我给自己定了个规矩：如果一个 if else 分支链从第一行读到最后一行，不超过一屏，且分支条件不重复，就直接写；如果超过一屏，去考虑抽象的时机到了。

7. 实操过程与常见问题排查

这部分我整理一些实战中经常踩的坑。每个坑都真实发生在我的项目里，踩一次，记一次，分享给后来的人。

7.1 分支条件顺序问题

有一次排查线上 bug，发现用户明明满足 A 条件，却走了另一个分支。原因是先判断了 B 条件，B 的判断范围包含了 A 的一部分场景。条件顺序在 if else 链里非常关键：范围更小的条件要放在前面，范围更大的放在后面。

常见错误写法：

java复制if (order.getAmount() > 100) {
    // 大额订单
} else if (order.getAmount() > 50) {
    // 中额订单
}

这里 amount = 80 的订单会走"大额"分支，因为 80 大于 50，在第一个条件里就满足了。正确写法是要把范围从大到小，或者从小到大，保持判断的次序与业务逻辑严格一致。这个 bug 很经典，我见过至少三个项目里犯过同样的错误。

7.2 多个条件合并时的短路逻辑

用 && 和 || 合并条件时，很多人会忽略短路求值的副作用。比如：

java复制if (order != null && order.getTotal() > 100) {
    // 没问题，先判空
}

if (order.getTotal() > 100 && order != null) {
    // 有问题！order 为空时直接 NULL 指针
}

第二个写法在 order 为空时抛异常。虽然很多人知道这个规则，但在实际编码时还是会写反。我在 code review 时，特意会把这个检查项列为必查项。这个问题的危险在于，有些情况下第一个条件也能偶发正常，比如 order 恰好不为空，于是 bug 被掩盖到了线上，等到某个边界条件触发才爆炸。

7.3 逻辑取反的可读性问题

条件判断里最折磨人的就是嵌套取反：

java复制if (!(order == null || order.getStatus() != PAID)) {
    // 什么时候会走到这里？
}

这种双层括号加上取反，读起来非常痛苦。对比一下：

java复制if (order != null && order.getStatus() == PAID) {
    // 一眼就看懂了
}

我在团队规范里立了一条规则：禁止在 if 条件里出现连续两个以上的取反运算。这不是严格意义上的法律条文，但有效避免了人脑在阅读时的短路。

7.4 多条件场景下的重构时机识别

什么时候该停止在 if else 上打补丁，直接上策略模式？我的个人观察点是：某个方法里 if else 分支超过 5 个，或者这个方法的圈复杂度超过 10，就该停下来，不能继续堆了。

这里聊到圈复杂度（cyclomatic complexity），它能很好地评估代码复杂度。工具的检查方式大同小异：SonarQube、Ide 插件、CI 检查都支持配置。我在 CI 里设了一条卡点：新增方法的圈复杂度超过 10，构建就报警。这个阈值让我团队的代码风格有了一个底线。

当代码开始不停复制"同样的条件分支"到多个方法里时，也应该考虑重构。比如订单模块，先是判断订单状态，然后计算费用，再判断状态，然后更新库存……状态判断逻辑散落各处。最好的做法是把订单状态当成一个对象，把可执行的操作封装在对象内部，调用方不需要再做状态判断。

8. 异步编程中的 if else：异常分支尤其要细心

前面已经提到 CompletableFuture，这里我展开说一说异步编程中条件判断的关键问题。异步和并发的代码，最大的特点是指令不按顺序执行。普通代码里 if else 的先后关系在异步代码里可能失效，这就埋下一大堆雷。

8.1 CompletableFuture 与 exceptionally 里的 if else

编写 CompletableFuture 异步流程时，多个异常类型的区分是一个高频场景。很多初学者会写出这样一段代码：

java复制future.exceptionally(throwable -> {
    Throwable real = throwable.getCause();
    if (real instanceof BizException) {
        return handleBiz((BizException) real);
    } else if (real instanceof RetryableException) {
        return retry();
    } else {
        return fallback();
    }
});

这里至少要清楚三件事：第一，exceptionally 里的参数是 CompletionException 包装过的，必须通过 getCause() 取底层异常；第二，参数类型本身还可能是 CompletionException，所以 getCause() 可能还有嵌套；第三，else 分支最好兜住所有未知异常，否则用户会看到 500 报错。

我写异步代码时的习惯是：先做一个异常剥壳的工具方法，把异常的嵌套剥到最底层，然后再做 if else 分类处理。这样写出来的代码既有 if else 的直观性，又不会在异常处理上翻车。

8.2 并发状态下的竞态条件

如果多个异步线程同时执行判断逻辑，就会出现竞态条件。比如判断一个账户余额是否充足，然后扣减：

java复制if (account.getBalance() >= amount) {
    account.deduct(amount);
}

并发情况下，线程 A 和线程 B 同时读余额都是 100，都通过判断，然后都执行扣减，最终余额可能变成负数。这个问题的根源不是 if else，而是"判断和操作"不是一个原子操作。解决方式有锁、原子类、数据库乐观锁等，但不管哪种方案，你都绕不开一个事实：并发下基于 if else 的判断必须放在事务或锁的边界内。

很多互联网公司订单扣减都遇到过类似 bug。这也是把 if else 用得"不坏"的一个关键点——你不仅要知道 if else 怎么写优雅，还要知道它在并发场景下的边界条件。

9. 用 AI 编程工具生成条件判断时的高效提示词技巧

现在大家项目里多多少少都用 AI 编程工具，Cursor 和 Claude Code 这类工具写 if else 的速度确实比我手写快很多，但生成的代码质量参差不齐。我自己调试出一套提示词模板，分享给大家。

9.1 在提示词里明确风格要求

直接说"写一个根据订单状态返回文本的方法"，AI 大概率会给出一大串 else if。但如果我加了风格约束，效果会大不一样：

code复制请实现一个方法 getOrderStatusText(String status)，返回订单状态对应的中文描述。
要求：
1. 优先使用 Map 或 switch 表达式，避免 else if 链
2. 未知状态返回"未知状态"，不要抛异常
3. 每分支一行，保持可读性

按照这种提示词生成出来的代码，基本不需要大改。如果团队对嵌套深度有要求，还可以加"嵌套层级不得超过两层"。AI 工具不是魔法，它遵循你给的约束。把团队规范写进提示词，等于把规范直接传导给 AI。

9.2 AI 生成条件判断的三类高频问题

第一，分支不全。AI 经常漏掉某个边界条件，比如没考虑 null 输入。你必须在提示词里特别点名"注意 null 输入"。

第二，条件顺序错误。比如像 7.1 节那样，AI 可能把大的范围写在前面，导致小范围的条件根本走不到。review 这种代码时要特别注意条件顺序。

第三，冗余分支。AI 有时候会生成永远走不到的分支，或者两个分支的逻辑完全相同。这种一般不会造成 bug，但它抬高了阅读成本。建议在 review 时顺手删掉。

AI 编程时代，if else 依然会存在，但它的"生成方式"变了。以前是手写，现在是提示词 + review。后半段依然需要人脑把关。

9.3 AI 生成的递归与条件判断案例

有个热搜词里提到一个递归算法：

code复制solve(n) if n <= 1 return 1 else if n >= 5 return n * solve(n - 2)

这种代码用 AI 生成很容易，但逻辑要对得上。这里有几个隐藏条件：n 小于等于 1 时返回 1，n 大于等于 5 时递归，但 n 等于 2、3、4 时呢？这段代码缺少 else 分支，没有覆盖中间值，所以在某些输入下会出现未定义行为。AI 常犯这类错误，因为它严格复述了你给的条件，但没意识到条件覆盖不全。

所以用 AI 生成递归或条件判断时，我建议在提示词里明确要求"枚举所有可能的输入情况，确保没有遗漏分支"。或者，review 时人工走一遍边界值。这类边界问题是 AI 编程的弱项，也是程序员的价值所在。

10. 项目规范建议：把 if else 的使用策略沉淀成团队文化

聊了很多技术思路，最后落回团队协作。如果整个团队对 if else 的容忍度不一，code review 就会变成无休止的争论。我强烈建议把 if else 的使用规范写进团队的编码规范文档里。不用写得很复杂，几条核心规则就行。

10.1 我在团队里执行的四条核心规则

第一，所有条件判断优先使用卫语句，禁止嵌套超过两层。这条规则直接拦住了最典型的垃圾代码。

第二，条件结果是"数据映射"类型的，全部用表驱动，禁止用 if else。各语言都支持 Map 或字典，几乎没有例外。

第三，条件分支"超过 5 个或内部逻辑复杂"时，主动考虑策略模式。不用强制，但要在 code review 时讨论。

第四，MISRA 等安全规范要求的场景，必须显式写 else 兜底并注释。这条针对嵌入式或安全关键项目，普通项目里我不强制。

这套规则最大的价值是减少争论。当 review 里出现分歧时，大家对照规范说话，而不是凭个人喜好争论。

10.2 把规则嵌入工具链

光有文档还不够，工具链的嵌入更重要。推荐几个做法：CI 里加复杂度检查；IDE 里装 SonarLint 或类似插件，实时提示嵌套太深；PR 模板里设置 code style 勾选项。工具化的好处是，规则不依赖人肉执行，而是自动化卡点。一旦有人提交了嵌套七层的代码，CI 直接失败，比 reviewer 写评论高效得多。

考虑到很多团队用 Cursor 这类 AI 工具，也可以把规范文件路径告诉 Cursor，让它自动遵循。这样 AI 生成的代码从一开始就符合团队规范，避免"生成即重构"。

11. 总结：if else 到底是什么水平

回到标题那道题："if else 是好代码吗？"

我的看法是：if else 本身是中性的，它是最贴近自然语言的编程结构，但也是极易被滥用的结构。一个程序员对 if else 的掌控能力，基本反映了 TA 对代码组织能力的理解深度。

初级程序员把 if else 当锤子，所有场景都是钉子；中级程序员学会了卫语句、表驱动、策略模式，开始"消灭" if else；高级程序员知道什么时候该用 if else、什么时候该替换，还会根据业务增长预判"这段代码半年后会变成什么样"。这三种状态我都经历过。

做 code review 这十几年，我见过最差的代码不是 if else 写的，而是"为了不用 if else 搞出一堆抽象"写的。真正的好代码，是让读的人理解成本最低的代码。它可以是 if else，也可以是策略模式，也可以是表驱动，关键看场景和上下文。

最后分享一个我常用的判断技巧：写完一段条件判断代码，第二天再读一遍，如果还需要仔细想"这个分支到底覆盖了哪些情况"，那就说明这段结构不够好，应该重构了。代码是写给未来的自己和其他同事的，降低理解成本，是最值得的投资。

如果你正在为一段 if else 纠结要不要重构，不妨拿这篇文章里的标准对照一下：嵌套超过两层了吗？分支超过五个了吗？分支内部逻辑复杂吗？有快速扩展的迹象吗？如果答案都是否，那这个 if else 大概率是好代码，安心提交就行。如果有一些是肯定的，恭喜你，你的代码在告诉你：该升级了。