Switch Code，从分支选择到模式匹配，switch 语句的进化与最佳实践

本文目录导读：

1. switch 的基本形态：清晰但有限
2. 进化：从 switch 到 switch 表达式
3. 何时该用 switch，何时该换一种思路？
4. 写安全、优雅的 switch code 的 4 条原则

在编程的世界里，条件分支是最基础也最常用的逻辑结构之一，而 switch 语句——即 “switch code”——作为多路分支的经典工具，经历了从 C 语言时代的紧凑 case 到现代语言中更强的模式匹配的进化，我们重新审视这段代码，看看它为何重要,以及如何用好它。

switch 的基本形态：清晰但有限

传统的 switch 语句像是一个多岔路口的指示牌，你给一个表达式，它在多个 case 之间寻找匹配，执行对应代码块，然后用 break 跳出，这种结构在处理枚举值、字符或有限整数集合时，比一连串 if-else 更加直观。

switch (dayOfWeek) {
    case MONDAY:
        System.out.println("周一");
        break;
    case FRIDAY:
        System.out.println("周五");
        break;
    default:
        System.out.println("其他日子");
}

传统的 switch 有两个明显痛点：fall-through（穿透） 和 类型限制，忘记加 break 会导致意外执行后续分支，这是许多 bug 的源头；而早期只能对整数、字符和枚举进行判断，对字符串、范围或复杂模式无能为力。

进化：从 switch 到 switch 表达式

近年来，主流语言开始对 “switch code” 进行重构，Java 12 引入了 switch 表达式，支持箭头语法和直接返回值，同时消除了 fall-through 的隐患：

String result = switch (day) {
    case MONDAY, FRIDAY -> "工作日头尾";
    case SATURDAY, SUNDAY -> "周末";
    default -> "平凡的一天";
};

C# 的 switch 更是演进为强大的模式匹配工具：

string description = shape switch
{
    Circle { Radius: > 10 } => "大圆",
    Circle => "小圆",
    Rectangle { Width: _, Height: 0 } => "线形矩形",
    null => "空对象",
    _ => "未知形状"
};

这种写法不仅简洁，而且能直接解构对象的属性、匹配 null、甚至组合模式，让 switch code 从简单的“相等比较”跃升为“基于结构的决策”。

何时该用 switch，何时该换一种思路？

很多人会问：有了 if-else 为什么还要用 switch？答案在于 可读性和扩展性。

• 处理枚举或固定集合：switch 天然胜出,一目了然。
• 类型区分（多态场景）：现代语言中用 switch 表达式做模式匹配，比用多态更小巧（尤其对封闭类型）
• 频繁增加分支：如果未来可能新加许多 case，不如考虑策略模式或映射表（Map<Key, Handler>），避免 switch 膨胀。

性能上，现代编译器和 JIT 会将紧凑的 switch 优化为跳转表（tableswitch）或二分查找（lookupswitch），在分支数超过 3 个时通常优于 if-else 链。

写安全、优雅的 switch code 的 4 条原则

1. 永远不要忘记 default 分支，即使你自信覆盖了所有可能，default 至少应该记录日志或抛出友好异常,防止新版枚举值被忽略。
2. 尽量用 switch 表达式替代语句，返回值直接绑定变量，减少副作用，也消除了意外 fall-through。
3. 避免在 case 中写复杂逻辑，每个 case 应只做一件事，复杂处理应抽取为方法，否则 switch 会变成“面条代码”。
4. 警惕 O(N) 的字符串 switch，某些语言对字符串 switch 实现为逐个 equals 比较，分支较多时性能不及 Map。

“switch code” 并非过时的遗留语法，而是伴随语言进化不断重生的利器，从 C 语言的紧凑控制流，到现代语言中表达力极强的模式匹配，switch 展示了“选择”这一基本语义如何优雅地适应不同抽象层次，理解它的优缺点，遵循最佳实践，我们就能在适当的场景里,让这段代码既快又清晰。