企业官网建设流程全解析

写代码这东西，很多坑其实不在语法本身，而在“选择结构”这种最基础的地方。if、switch几乎每个程序都在用，但你随便打开一个项目的代码，大概率能看到一堆可以优化的分支逻辑——要么 if 套 if 套了五六层，要么 switch 里漏了 break 导致一串意外执行，要么条件顺序写反，结果程序跑了一整年都没人发现某个分支从来没进过。

这篇内容我打算把 if 和 switch 彻底讲透。主线以 C 语言为基准，因为 C 的语法最朴素、坑也最经典，你把这个版本的机制弄懂了，再看 Java、JavaScript、Python 这些语言里的分支结构，基本就是换层皮的事。我会从它们的执行原理、适用场景、选择标准讲到实战代码和常见问题排查，顺便把我在实际项目里踩过的坑、总结出来的经验一并放进来，希望能帮你少走点弯路。

如果你是刚学编程不久的新手，这篇文章可以帮你把基础打扎实；如果你已经写了几年代码，也不妨扫一眼，有些细节——比如 C 语言 switch 的 case 常量限制、悬空 else、短路求值带来的隐含影响——可能写代码时都未必仔细想过。

1. 选择结构为什么值得重新认真学一遍

1.1 从一段真实代码说起

我有一次帮同事 review 代码，看到一个函数，作用是处理用户输入的命令，大概有七八种命令，每种要做的事不一样。这位同事用的思路是写一长串 if else，每个分支里再嵌套好几个 if 判断参数是否合法。整个函数拉下来八十几行，读起来非常吃力。

我当时的评价是：这代码能跑，也没 bug，但维护成本太高。后来我把这段逻辑整理了一下，把命令分门别类，做成一个 switch 结构，主干清爽了很多，后面再想加新命令也方便。后来我问同事为什么一开始不用 switch，他说“感觉 switch 好像限制了条件，不太灵活”。

这就是很多人的误区。if 适合表达“条件判断”，switch 适合表达“精确匹配”。两种结构没有谁更高级，而是服务不同的场景。用错了，代码虽然也能跑，但会别扭，事后维护的人会非常难受。

1.2 if 和 switch 的执行机制完全不同

理解一样东西，先理解它的底层机制，比死记语法有效得多。

if 结构的核心机制是：对条件表达式求值，得到一个真或假的结果，然后决定走哪条路。它的条件可以是任意表达式，比如x > 10、a == b && c != 0，甚至是一个函数调用，只要你最终能得出布尔值就行。多个 else if 的本质是“逐个问询”：第一个条件满足就不再问后面的了。

switch 的核心机制是：先对括号里的表达式求一次值，得到一个结果，然后拿这个结果和每个 case 后面的常量比较。一旦匹配上，就从这个 case 开始顺序执行，直到遇到 break 或者整个 switch 结束。关键在于：switch 只“求一次值”，然后做的是“查表匹配”，所以它在应对大量离散取值时，语义上更清晰，性能上也可能有优势。

用生活化的类比来说：if 像过安检，你得过好几道检查口，每个口问一个问题，符合就放行；switch 像快递自动分拣，包裹上的标签扫一下，机器自动把包裹拨到对应的滑槽里。

理解了这两个机制的区别，后面所有细节——为什么 case 要写常量、为什么容易“穿透”、为什么 if 能做范围判断而 switch 很别扭——就都顺理成章了。

2. if 语句的完整拆解与实操要点

2.1 三种基础形态：从最简单到最常用

if 语句在 C 语言里有三种基本形态。第一种是单分支，只判断一个条件，为真就执行，为假就跳过：

if (score >= 60) { printf("及格了\n"); }

第二种是双分支，加上 else，非此即彼：

if (score >= 60) { printf("及格了\n"); } else { printf("没及格\n"); }

第三种是 else if 链，用来处理多个互斥的条件：

if (score >= 90) { printf("优秀\n"); } else if (score >= 80) { printf("良好\n"); } else if (score >= 70) { printf("中等\n"); } else if (score >= 60) { printf("及格\n"); } else { printf("不及格\n"); }

这里提醒一点：else if 不是 C 语言的关键字，它本质上就是“else”后面跟着一个“if 语句”，只不过写的时候省略了大括号。很多初学者会把else if当成一个整体，其实拆开来看就是：

else { if (score >= 80) { ... } }

理解这一点很重要，因为有的新手会在else和if之间加个分号，或者把else if换行写，导致语法错误，根本原因就是没明白它不是原子语法。

2.2 悬空 else：缩进骗不了编译器

C 语言里有一个经典老坑，叫“悬空 else”。它的核心是：else 总是和离它最近的、尚未配对的 if 结合，而不是和缩进对齐的那个 if 结合。

if (a > 0) if (b > 0) printf("a 和 b 都大于0\n"); else printf("这里到底是哪个 if 的 else？\n");

从缩进看，你可能会以为这个 else 是配对外层if (a > 0)的，但实际编译器会把它配对内层那个if (b > 0)。也就是说，这段代码的逻辑其实是：

if (a > 0) { if (b > 0) { printf("a 和 b 都大于0\n"); } else { printf("这里到底是哪个 if 的 else？\n"); } }

这是个非常容易踩的坑。我见过不少初级工程师写嵌套 if 时不加大括号，结果后面加需求的时候，新加的 else 匹配错了层级，程序行为完全变了，还特别难排查。我的建议是：写 if 语句时永远不要省略大括号，即使分支里只有一行代码。这样既避免悬空 else 的问题，也避免以后往里加代码时忘记加括号导致的逻辑错乱。

2.3 短路求值：既是利器也是陷阱

C 语言里，&&和||都有“短路求值”（short-circuit evaluation）的特性。什么意思呢？A && B，如果 A 已经是假，那么 B 根本不会被求值，因为整个表达式必然是假；A || B，如果 A 已经是真，B 也不会被求值。这个特性用好了能避免很多运行时错误，用不好则是隐蔽 bug 的来源。

最常见的用法是用来保护“空指针”或者“除零”，比如：

if (p != NULL && p->value > 100) { // 先判断 p 不是空，再访问 p->value // 如果 p 是空，第二个条件不会执行，不会崩 }

再比如判断一个数能否作为除数之前，先判断它不为零：

if (b != 0 && a / b > 10) { // b 为 0 时，后半段不会执行，不会出现除零错误 }

这个特性如果被忽略，就会出现问题。比如有人为了省事把条件顺序写反：

if (a / b > 10 && b != 0) { // 先求值 a / b，这里如果 b 是 0，直接崩溃 }

代码不会按你心里的“逻辑顺序”执行，它只按表达式的书写顺序执行。所以写条件时，一定要把“保护性判断”放在前面，把“可能出错的访问”放在后面。这个习惯能帮你避开大量空指针崩溃。

2.4 经典陷阱：浮点比较、赋值号和空语句

if 判断里有三个老生常谈但总是有人犯的错，值得单独列出来说一下。

第一个是浮点数直接比较相等。float f = 0.1;然后判断if (f == 0.1)，很可能不成立。原因是浮点数在计算机里是二进制表示的，0.1 无法被精确表示，存储的是一个近似值，所以直接比较相等非常不可靠。正确做法是比较它们的差是否在某个容差范围内：

double f = 0.1 + 0.2; if (f - 0.3 < 1e-9 && f - 0.3 > -1e-9) { printf("f 约等于 0.3\n"); }

或者用fabs(f - 0.3) < 1e-9，更简洁。

第二个是把赋值号=当成等号==。这个坑很多人第一天学 C 语言就踩过，但踩了一次之后可能还会再踩。比如：

if (x = 0) { // 这是把 0 赋给 x，赋值表达式的值是 0，即假，所以这个分支永远不会进 }

这个 bug 最坑的地方在于编译不报错，程序也能跑，但行为完全不对。不少编译器会给出警告，所以开发时一定要把编译警告开起来，别忽略警告信息。有个老技巧可以降低风险：把常量写在左边，if (0 == x)，如果少写一个等号变成if (0 = x)，编译会直接报错。这个写法对数字比较有效，但不要在所有地方强行套用，可读性上大家习惯不同，团队内约定好即可。

第三个是空语句问题。比如：

if (x > 10); { printf("x 大于10\n"); }

注意 if 条件后面直接跟了一个分号，分号表示 if 的语句体是一个空语句。不管条件成不成立，下面那个大括号里的代码都会执行。这就是典型的“条件失效”bug。排查这种问题，看到 if 行尾的分号就要警觉。这也是为什么我一直强调大括号不要省——省的时候很容易把分号看成语句的结束。

2.5 条件顺序与性能的微妙关系

在实际代码里，else if 的分支顺序直接影响程序的性能，虽然单个判断的耗时可能只是纳秒级，但如果这段代码在一个大循环里执行十万次，差距就会积累起来。

原则是：把最可能发生的情况放在最前面。比如处理 HTTP 状态码时，200 是主要成功状态，应该放在最前面的判断里，让大部分请求只经过一两次比较就返回；500 这种稀少错误放在很后面，反正很少走到。

另一个容易被忽略的点是：条件之间有重叠时，起决定性作用的判断要先写。比如根据分数分等级，如果先判断score >= 60，再判断score >= 90，那 95 分的人早就被第一个分支拦截了，根本到不了第二个分支。所以用 else if 时，条件顺序要么从窄到宽，要么从宽到窄，必须按逻辑上有“优先级”的顺序来，否则就会出现分支死代码。

3. switch 语句的完整拆解与实操要点

3.1 基本语法和执行流程

switch 的标准写法如下：

switch (表达式) { case 常量1: 语句1; break; case 常量2: 语句2; break; default: 默认语句; break; }

执行流程可以拆成几步：

• 先对括号里的表达式求值，得到一个结果。
• 然后从上到下，把结果和每个 case 后面的常量进行比较。
• 如果匹配到某个 case，就从这个 case 后的第一条语句开始执行，一直执行到 break 跳出整个 switch。
• 如果没有匹配到任何 case，就执行 default 后面的语句。

这段流程里最关键的一点是：匹配成功后，是从当前 case 开始“往下顺序执行”，而不是只执行这一条。这就是为什么会发生“case 穿透”：如果你在某个 case 后面忘了写 break，程序不会自动停下，而是会继续执行下一个 case 的语句，直到遇到 break 或 switch 结束。

3.2 case 穿透：最经典的 switch 坑

很多人第一次被 switch 坑，就是漏了 break。看这个例子：

int n = 2; switch (n) { case 1: printf("one\n"); case 2: printf("two\n"); case 3: printf("three\n"); default: printf("other\n"); }

猜猜输出是什么？不是简单的 “two”，而是：

two three other

因为 n 匹配 case 2 之后，后面的每个 case 也跟着执行了。这就是穿透。

但穿透并不总是坏事。“故意穿透”是一个常见的合法用法，用来把多个值合并到同一段处理逻辑。比如：

switch (month) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: printf("这个月有31天\n"); break; case 4: case 6: case 9: case 11: printf("这个月有30天\n"); break; case 2: printf("2月比较特殊\n"); break; default: printf("无效月份\n"); break; }

这种写法把 case 1、3、5 等合并到同一个处理分支，非常自然，读代码的人也知道你是故意这么写的。所以关键不在于“能不能穿透”，而在于要么每个 case 都以 break 结尾，要么用注释明确标注“故意不写 break，让多个 case 合并”。不加注释也不写 break，多半是 bug。

3.3 C 语言 switch 的两个硬性限制

C 语言的 switch 有两个限制，跟 if 相比是明显的短板。

第一个限制：case 后面的值必须是整型常量表达式。整型包括 int、char、枚举等，但不包括浮点数，也不能是变量。下面的写法是错误的：

double d = 0.5; switch (d) { // 错误：switch 表达式不能是 double case 0.5: // 错误：case 不能是浮点数 ... }

char 能用于 switch 是因为 char 本质上也是整型。比如判断用户输入的字符：

char c = getchar(); switch (c) { case 'y': case 'Y': printf("确认\n"); break; case 'n': case 'N': printf("取消\n"); break; default: printf("无效输入\n"); break; }

第二个限制容易踩坑：const变量不是“常量表达式”。在 C 语言中，const int a = 3;只是说 a 的值不能改，但编译器不认为它可以作为 case 的标签值。要定义真正可用于 case 的常量，得用宏定义或者枚举：

#define CMD_OPEN 1 #define CMD_CLOSE 2 enum { CMD_START = 1, CMD_STOP = 2, CMD_RESET = 3 };

很多初学者在这个地方卡过：明明const int x = 1;写得好好的，放到 case 后面编译直接报错。理解“常量表达式”这个概念以后，就不会再被这个问题困扰了。

3.4 实战：用 switch 写一个迷你状态机

switch 特别适合实现状态机，因为状态机的核心就是“当前状态 + 事件 → 下一个状态”。这种场景天然是离散匹配。

假设我们要写一个简单的开关控制流程，设备有四个状态：待机（IDLE）、运行（RUNNING）、暂停（PAUSED）、停止（STOPPED），事件有启动（START）、暂停（PAUSE）、恢复（RESUME）、停止（STOP）。用枚举定义状态和事件：

enum State { IDLE, RUNNING, PAUSED, STOPPED }; enum Event { START, PAUSE, RESUME, STOP }; enum State next_state(enum State current, enum Event event) { switch (current) { case IDLE: if (event == START) return RUNNING; break; case RUNNING: if (event == PAUSE) return PAUSED; if (event == STOP) return STOPPED; break; case PAUSED: if (event == RESUME) return RUNNING; if (event == STOP) return STOPPED; break; case STOPPED: if (event == START) return RUNNING; break; default: break; } return current; // 没有合法转移，保持原状态 }

外层用 switch 处理不同状态，内层用 if 判断在当前状态下哪个事件有效。这种“switch 分状态 + if 判事件”的组合，比一长串 if else if 容易读得多，加了新状态、新事件也容易定位到对应位置修改。

如果事件的处理逻辑比较复杂，还可以再用一层 switch 对事件做分发，但两层 switch 嵌套可读性会降低。更大的项目里，更推荐用函数指针表或者表驱动的方式，这个我在后面第 4 节会专门讲。

4. if 和 switch 如何选型：场景对照与组合用法

4.1 选择标准：不是凭感觉，而是看数据结构

我见过不少人写分支的时候下意识用 if，不管什么场景。其实选型标准很简单，核心就一条：if 适合范围与复合条件判断，switch 适合离散值精确匹配。

具体来说，满足这些条件时优先考虑 switch：

• 判断的依据是同一个变量（或表达式）的取值。
• 取值是离散的、有限的。
• 取值的数量大于两三个。
• 每个取值对应的处理逻辑相对独立。

满足这些条件时用 if 更合适：

• 判断的依据涉及多个变量。
• 条件是范围比较，比如x > 10 && x < 50。
• 条件本身是复合逻辑，比如(a == 0 && b != 0) || c。
• 比较的值是浮点数或者无法枚举的字符串（C 语言中，Java 和 JS 的 switch 支持字符串，这是语言差异）。

比如根据分数判断等级，这个用 if 就很自然，因为它是一个连续范围；如果你非要用 switch，就得列一堆 case 把每个分数枚举出来，从 0 到 100，既笨拙又容易漏。反过来，处理菜单命令、协议类型、操作符优先级这类离散值，switch 则更清晰、修改也更集中。

4.2 什么时候绝对不要用 switch

C 语言里有一个场景绝对不要用 switch：你要比较的是字符串。C 语言的字符串是 char 数组，不是基本类型，不能作为 switch 表达式，也没法直接用==比较。很多 C 项目里对字符串命令的处理是这么写的：

if (strcmp(cmd, "open") == 0) { do_open(); } else if (strcmp(cmd, "close") == 0) { do_close(); } else if (strcmp(cmd, "reset") == 0) { do_reset(); } else { error(); }

这种写法本身没什么问题，但如果命令数量很大，一长串 strcmp 会显得重复。更优雅的方案是查表，把命令字符串和对应的处理函数放在一张表里，用循环匹配，后面加命令只需要往表里加一行。

另一个不要用 switch 的场景是判断边界值容易出错的业务规则。比如判断年份是否是闰年，条件里有“能被 4 整除但不能被 100 整除，或者能被 400 整除”这种公式，用 if 表达直接清晰，硬套 switch 只会把代码搞得没人能看懂。

4.3 一种被低估的替代方案：查表法

当 case 数量非常多，或者 case 的处理逻辑只是“把值映射到另一个值”的时候，其实可以整段 switch 都不写，直接用查表法。

最简单的查表是把映射关系放在数组里。比如把星期数字（1~7）映射成中文名字：

const char *names[] = {"", "周一", "周二", "周三", "周四", "周五", "周六", "周日"}; int day = 3; if (day >= 1 && day <= 7) { printf("%s\n", names[day]); } else { printf("无效星期\n"); }

比写七个 case 的 switch 简洁得多，而且当天数增加到几十个，数组长度跟着加就行，代码结构不变。前提是映射关系的下标必须是连续的整数，这样才能直接用数组下标。

对于更复杂的命令处理，可以用“函数指针数组 + 结构体表”的方式。比如一个简易的命令处理器：

struct Command { int id; void (*handler)(void); }; void cmd_open(void) { printf("执行打开\n"); } void cmd_close(void) { printf("执行关闭\n"); } void cmd_reset(void) { printf("执行重置\n"); } struct Command cmd_table[] = { {1, cmd_open}, {2, cmd_close}, {3, cmd_reset}, }; void process_command(int id) { size_t i; for (i = 0; i < sizeof(cmd_table) / sizeof(cmd_table[0]); i++) { if (cmd_table[i].id == id) { cmd_table[i].handler(); return; } } printf("未知命令 %d\n", id); }

这样做的好处是：新增命令时不需要改动 process_command 主逻辑，只需要往表里加一行。这种“对修改关闭、对扩展开放”的效果，在代码维护上价值很高。反过来，如果使用 switch，每加一个命令就要在 switch 里加一个 case，主函数会越变越长，最后成为一个几百行的“神仙函数”。

5. 多语言横评：Java、JavaScript、Python 是怎么玩分支的

5.1 Java 里的增强版 switch

Java 的 switch 在传统语法上和 C 语言非常像，同样有 case 穿透，需要写 break，case 值最早只能是常量。但 Java 14 之后推出了增强版 switch，语法和语义都变化很大：

String type = switch (day) { case 1, 2, 3, 4, 5 -> "工作日"; case 6, 7 -> "周末"; default -> "无效日期"; };

这里有几个重要变化：一是箭头->后面直接是返回值或表达式，不再需要 break，也不会有穿透；多个值可以用逗号合并到同一个分支；整个 switch 可以作为一个表达式“产生一个值”赋给变量。这个语法比 C 语言老版 switch 安全很多，可读性也更好。

Java 里还有一个细节和 C 语言不同：Java 的 switch 支持字符串。你可以写switch (cmd) { case "open": ... }，这在 C 语言里做不到。字符串匹配底层是用 hash 实现的，挺高效。

5.2 JavaScript 的 switch：穿透还在，比较是全等

JavaScript 的 switch 语法跟 C 语言一脉相承，同样有 case 穿透问题，需要写 break。但它有两个细节值得注意：

第一个细节是 switch 的比较是全等比较（===），不是宽松相等（==）。这意味着 case 里写数字 1，和字符串 "1" 不会被匹配。比如：

let n = "1"; switch (n) { case 1: console.log("数字1"); break; case "1": console.log("字符串1"); break; }

这里匹配的是第二个 case。如果你以为它匹配了第一个，逻辑就错了。

第二个细节和 C 语言一样会坑人：穿仍然存在。很多 JS 开发者写 switch 时漏了 break，程序行为随之失控。我个人在 JavaScript 里写 switch 的建议是：确认每个 case 都以 break、return 或 throw 结尾；想合并多个 case 时，显式地把 case 堆在一起，让人一眼看出这是故意的。

5.3 Python 没有 switch，但它有 match-case

很多从 C 语言转 Python 的人都会问：Python 为什么没有 switch？答案很长，但简单说就是 Python 的设计哲学是“尽量只有一种方式来做一件事”，而传统 switch 能用 if/elif 替代，就没有引入。不过 Python 3.10 引入了 match-case 语句，虽然不是传统意义上的 switch，但功能上能覆盖大量类似场景：

command = "open" match command: case "open": print("执行打开") case "close": print("执行关闭") case _: print("未知命令")

注意 match-case 的每个分支不需要 break，匹配成功后不会穿透。case _相当于 default。更强大的是它支持“结构化模式匹配”，可以直接解包元组、匹配类型，比如：

def process(point): match point: case (0, 0): print("原点") case (0, y): print(f"在 y 轴上，y={y}") case (x, y) if x == y: print("x 等于 y") case (x, y): print(f"普通点 {x}, {y}")

这种模式匹配能力比传统 switch 强太多了。但在 Python 里面，如果你的场景只是简单离散值匹配，很多人依然习惯用字典映射：

handlers = { "open": do_open, "close": do_close, "reset": do_reset, } handler = handlers.get(command, unknown) handler()

这种写法贴近前面说的查表法，在很多场景下比 match-case 更简洁。

5.4 Go 和 Rust 的另类思路

Go 语言里没有三元运算符，和 if 相关的坑少了一个，但它的 switch 很有意思：每个 case 默认自动 break，不需要你写；还允许 case 后面跟多个条件用逗号分隔。最特别的是，Go 的 switch 允许不带表达式，直接当 if-else-if 链用：

switch { case score >= 90: fmt.Println("优秀") case score >= 80: fmt.Println("良好") default: fmt.Println("加油") }

这种写法等于给 if-else-if 链换了个更清晰的壳，条件仍然是范围判断。

Rust 更进一步，用的是 match 表达式，强制要求穷尽所有可能，否则编译不通过。这种设计从编译器层面杜绝了“漏掉某种情况”的 bug，对代码完整性要求极高。这两种语言的思想说明了现代语言在分支结构上考虑的问题更多是“可读性”和“安全性”，而不只是语法便利。

下面这个表可以一目了然：

6. 常见问题与排查技巧实录

6.1 分支行为异常排查思路

写选择结构代码遇到“结果不对”的时候，先别急，按下面的思路排查效率最高：

问题是“某些代码似乎没执行”或者“多执行了一段”，优先检查 if 条件、大括号匹配和 switch 的 break。如果是 else if 链，把所有可能的分支条件都列出来，对比一下有没有重叠、有没有没覆盖到的区间。特别是用>=、>这些边界条件时，把边界值代入算一算。

我在一个项目里碰到过有趣的 bug：判断月份天数时条件写成了if (month <= 7 && month % 2 == 1)，结果把 8 月以后的处理搞混了，原因就是没有想清楚“1-7 月奇偶规律”和“8-12 月反过来”这个分界。用表格列出每个月的实际天数，再对照代码条件，问题立刻就能看出来。

排查时有一个非常有用的技巧：在 key 分支里插入临时打印或日志。不要觉得这一步啰嗦。打印每个分支的命中情况和关键变量值，很快就能定位是哪个条件判断出了问题，比盯着代码干想快得多。

6.2 常见问题速查表

6.3 可读性细节：default 位置、break 约定

关于 default 的位置，老派写法喜欢放最后，但现在很多人建议把 default 放在第一个，尤其是在处理命令分发、错误优先的场景。理由是：你希望程序遇到“未知值”时立刻发现并处理，而不是一路匹配到最后才发现不匹配。这种写法读代码的人一进 switch 就知道未知情况会走到哪，安全感强不少。

当然，default 放最后也有它的道理——顺着 case 列表读下来，最后的兜底逻辑很自然。我的建议是：团队约定统一即可，关键是不要混乱。如果项目已经统一了某个风格，就跟着走，不要一个人特立独行。

break 的约定就更重要了。我在代码评审时发现过太多穿透 bug，后来我们团队统一约定：每个 case 的代码结束必须显式写 break 或 return，不允许依赖“最后一个 case 不写 break 也不会出问题”这种写法。虽然最后一个 case 在 break 上确实可以不写，但一旦以后有人在这个 case 后面新增一个 case，原来的代码就在无意识中产生了穿透 bug。

6.4 条件别写复杂了：早返回是最大功臣

最后分享一个我自己的习惯：写 if 嵌套时，尽量用“早返回”策略，把异常和边界情况提前处理掉，减少嵌套层级。

看一个典型例子。原始代码长这样：

if (p != NULL) { if (p->type == TYPE_A) { if (p->size > 0) { do_process_a(p); } } }

嵌套了三层，读起来很费劲。用早返回改一下：

if (p == NULL) { return; } if (p->type != TYPE_A) { return; } if (p->size <= 0) { return; } do_process_a(p);

逻辑等价，但每一层都是平铺的，读代码时不需要维护“我现在在第几层括号里”的心智状态。尤其在函数前面有一堆前置条件校验时，这种写法非常舒服，新来的同事看得也明白。这其实不是 if 本身的问题，而是代码风格问题，但它能让 if 用起来舒服得多。

我在实际项目里还有一个习惯：如果一个函数里分支判断超过三四个，而且每个分支逻辑都比较长，就把分支里的逻辑提取成单独的函数。这样 main 函数只保留“决策”的部分，每个分支做什么一目了然，也不用跳到一半发现这个函数已经读不完。

选择结构用得好不好，决定了一个人写复杂逻辑时会不会把自己绕晕，也决定了别人看你代码时是觉得“这个入口很清楚”还是“这地方没人敢动”。这些经验都不是什么高深理论，多数是在一次次排查 bug 和代码评审里磨出来的。下次写 if 和 switch 之前，先停顿两秒，想清楚这里是“范围判断”还是“离散匹配”，再动手，代码质量会明显不一样。