直接说结论：如果你刚开始学C语言，或者学了几个月还是经常在if/switch上翻车，这篇就是给你写的。
选择语句（if-else、switch-case）是C语言里用最频繁、但又是被误解最多的一块。我见过太多人写了好几年C，遇到"else到底跟哪个if配对"、"case里到底要不要break"、"为什么条件判断里用==总是写成了="这类问题，脑子还是要卡壳。热搜词里也出现了"c语言运算符优先级"、"c语言while和do-while区别"、"c语言基础知识"这些高频词，说明大家卡住的点往往不是语法本身，而是语法背后的规则和边界。
这篇文章不打算从"什么是if语句"这种教科书式开头讲起，而是直接用我实际调试过的代码案例，把选择语句里那些文档不会明说、但实战一定会踩的细节全部拆开讲。适合三类人：刚入门需要把基础砸实的新手，准备C语言考试（比如PTA、GESP、CSP这类，热搜里这些题目的出现频率很高）需要系统理清知识点的学生，以及工作中写嵌入式或底层代码、想少写几个隐蔽bug的工程师。
1. if-else的隐藏规则：else配对、空语句与嵌套陷阱
if-else大概是C语言里"看起来最简单、实际最容易错"的语法结构。它的核心规则其实只有一条：else永远与离它最近的、尚未配对的if结合。这句话背下来容易，真正遇到问题的时候，很多人照样栽跟头。
1.1 悬空else问题：一个真实的调试案例
先看这段代码，是我之前调试一个温度采集程序时遇到的：
int status = read_sensor(); if (status >= 0) if (status > 50) printf("高温警告\n"); else printf("传感器异常\n");这段代码的本意是：如果状态值正常且温度大于50就报警，如果状态值小于0就报"传感器异常"。
但实际上，不管status是-5还是30，程序都不会打印"传感器异常"。
原因就是那条隐藏规则：else匹配的是离它最近的那个if，也就是status > 50这个if，而不是status >= 0这个if。所以当status为-5时，外层if不成立，整个嵌套结构（包括else）都不会执行。
如果你想让else匹配外层if，必须用大括号把内层if"隔离"出来：
if (status >= 0) { if (status > 50) printf("高温警告\n"); } else { printf("传感器异常\n"); }这个坑在C语言经典著作里被反复提及，但直到今天，我在Code Review里还是能经常看到类似的代码。说实话，不怪程序员粗心，这本身就是C语言语法设计里最容易引起误解的地方之一。
我的建议很直接：不管if后面跟几条语句，一律写大括号。哪怕只有一行，也写上{}。这不仅仅是风格问题，它能从根本上杜绝这类"悬空else"逻辑错误。
1.2 else if的本质：它不是语法，是嵌套的缩写
很多初学者会把else if当成C语言的一个独立语法关键字，这是个常见的认知误差。
else if其实只是两个关键字的组合：一个else加上一个if。也就是说：
if (a > 0) { // A } else if (a < 0) { // B } else { // C }本质上等价于：
if (a > 0) { // A } else { if (a < 0) { // B } else { // C } }理解这个等价关系有什么用？用处大了。它决定了else if链中每个条件的"前置条件"是隐式的。比如上面这个例子，执行到else if (a < 0)时，说明a > 0已经是false了，所以a要么小于等于0，这时候再判断a < 0就是有意义且不冗余的。
但换一种写法，有些人喜欢把条件写成else if (a <= 0 && a < 0)，这就是完全多余的，因为进入else if时a <= 0已经成立了。
判断冗余条件这件事，考试和面试时很爱考。比如：
if (x >= 10) { // A } else if (x >= 5) { // B } else if (x >= 0) { // C }到第二个分支时，x必然小于10，所以只需要写x >= 5，隐含了5 <= x < 10。第三个分支同理。很多人会在这里纠结要不要写x >= 0 && x < 5，其实不需要，写了反而显得对else if的语义理解不到位。
1.3 条件判断中的真假值：不仅仅是0和非0
C语言里没有真正的布尔类型（C99引入了_Bool，但和C++的bool仍有区别），条件表达式的结果是一个整数值。
判断规则极其简单：0为假，非0为真。
这个规则导致了一个非常实用但也很容易出错的场景。比如判断一个指针是否为空：
char *p = malloc(100); if (!p) { // 内存分配失败 }这里的!p等价于p == NULL，因为NULL在C语言里就是(void*)0，值为0。
再比如判断一个数是否为奇数：
if (n % 2) { // n是奇数 }因为n % 2的结果只有0或非0两种可能，直接用这个值做条件既简洁又高效。
但是！正因为"非0即真"这个规则，很多隐蔽bug就来了。比如把逻辑与运算符&&和按位与运算符&搞混：
if (a & b) // 按位与，只要结果非0就为真 if (a && b) // 逻辑与，需要a和b都为真3 & 1的结果是1（二进制11与01按位与），为真；3 && 1的结果也是真，但如果换成3 & 2，结果是2，也为真，而3 && 2同样为真——这俩在多数情况下结果一致，可一旦值变成2 & 4，结果为0为假，而2 && 4为真。差距一下就出来了。
建议：逻辑判断用&&、||、!；位运算用&、|、~、^。两者混用就是给自己埋雷。
2. switch-case专题：case穿透是真坑还是真本事
switch-case是另一种选择结构，它和if-else最大的不同在于：switch是"跳转表"式的选择，而if-else是"条件判断"式的选择。这个底层差异决定了它们在很多场景下的性能表现和代码风格截然不同。
2.1 break缺失：初学者必踩的大坑
switch-case的判定流程是：找到匹配的case，从该case开始顺序执行，直到遇到break或switch结束。
也就是说，如果不写break，程序会"穿透"到下一个case继续执行。看这个经典例子：
int score_level = 2; switch (score_level) { case 1: printf("等级A\n"); case 2: printf("等级B\n"); case 3: printf("等级C\n"); default: printf("未知等级\n"); }运行结果会同时打印"等级B"、"等级C"、"未知等级"三行。
问题出在case 2后面没有break，程序执行完case 2的语句后，继续往下执行了case 3和default的语句。
这里有一个考试和面试的高频考点：case穿透是语法允许的行为。也就是说，C语言编译器不会因为你忘了写break而报错，它把这当成你的"本意"。所以，检查代码时一定要把每个case对应的break单独查一遍。
2.2 故意穿透：一种有用的编程技法
case穿透不全都是bug。在某些场景下，它是刻意的设计。
比如，你希望多个case共享同一段处理逻辑：
char grade = 'B'; switch (grade) { case 'A': case 'B': case 'C': printf("成绩合格\n"); break; case 'D': case 'F': printf("成绩不合格\n"); break; default: printf("无效成绩\n"); break; }这里case 'A'、'B'、'C'都执行的是"成绩合格"的逻辑，无需每个case都写一遍printf。这种模式在工业代码里非常常见，尤其是状态机处理中，多个状态进入同一个动作时。
区分"故意穿透"和"遗忘break"有个简单的办法：代码审查时，凡是连续case之间没有break的，要么注释说明"fall through"，要么用编译器属性标记（比如GCC的__attribute__((fallthrough))）。在C17标准里，已经有了[[fallthrough]]属性，Clang和GCC都被要求支持。
我自己写代码的习惯是：如果case间故意不写break，一定加一行注释/* fall through */。这样既方便维护，也能防止后续接手的人误加break破环逻辑。
2.3 switch和if-else的选用标准：性能不是唯一维度
很多人在switch和if-else之间犹豫，主要纠结性能。
实际情况是：当case的分支数量比较多（一般编译器优化阈值在3~5个以上），且case标签的值比较密集（比如1到10连续）时，编译器有条件把switch优化为跳转表，此时switch的性能确实优于if-else链。但case值比较稀疏（比如1、100、1000），编译器可能退化为二分查找甚至线性比较，此时性能和if-else差不多。
所以，选哪个不应只看性能，更要看代码的表达力：
- 条件涉及范围判断（如
x > 0 && x < 10）、复杂逻辑组合（如a == 1 && b == 2）时，用if-else。 - 条件是对单个变量的离散值进行匹配时，用switch更清晰。
- 需要从多个值映射到同一动作时，switch的穿透特性比if-else更简洁。
- 要在运行时动态判断分支数量，switch通常不如if-else灵活。
另外补充一个点：热搜词里出现了"c语言和java和python和c++"这类对比需求，不少读者可能也学过其中一两种语言。这里特别提醒，C语言的switch和Java/C++的switch有个关键差异：在C语言中，case标签必须是整数常量表达式，不能是字符串；而在Java中（从Java 7开始）switch可以判断字符串，C++则依然不行。在C语言里如果需要对字符串做多路选择，必须用strcmp配合if-else链，或者先用哈希函数把字符串映射成整数再switch。
2.4 default位置与省略规则
default是switch里的"兜底"分支，它的位置在语法上非常自由，可以放在任意case之前或之后，甚至放在所有case的最前面。
但位置会影响执行顺序。比如：
switch (n) { default: printf("未匹配\n"); break; case 1: printf("一\n"); break; case 2: printf("二\n"); break; }当n等于2时，会直接跳到case 2执行，不会先执行default。只有当n不匹配任何case时，才会从default开始执行。
所以default放哪都不会"误伤"正常匹配，但为了让代码读起来舒服，我建议default永远放在最后。别为了标新立异放前面，这在代码维护时会让读者产生不必要的困惑。
还有一种情况：你明确知道变量只会取某些值，但又不确定实际运行时会是什么，这时候default要用来做异常兜底：
switch (mode) { case MODE_A: handle_a(); break; case MODE_B: handle_b(); break; default: // 理论上不该走到这里，但为了防止意外，记录日志 log_error("unknown mode: %d", mode); break; }这种"防御性默认分支"在嵌入式开发里尤为重要。我见过不少无人机飞控、电机控制代码，就是靠这个default兜底，在状态异常时及时切断输出或进入安全模式。
3. 条件表达式里的优先级陷阱：为什么你的if老是"不听话"
选择语句的核心是条件表达式。而条件表达式里，运算符优先级是C语言中最容易出问题的地方之一，热搜词里"c语言运算符优先级"赫然在列，也说明这个问题的普遍性。
3.1 赋值"=="与比较"==="的经典混淆
这是C语言初学者最著名的坑：
if (a = 1) { // 这个分支永远会执行 }问题在于：a = 1是赋值语句，不是比较。它的执行过程是：把1赋给a，然后整个表达式的值就是a被赋的值，也就是1。1是非0，为真，所以这个if永远成立。
相比之下：
if (a == 1) { // 只有当a等于1时才成立 }才是真正的比较。
为什么会有这么多人把=和==搞混？因为很多编程语言（比如Python）不允许在if条件中直接赋值，写错了编译器会报错。但C语言允许赋值作为表达式出现在任何地方，编译器通常只给警告（warning）而不报错（error）。默认配置下，GCC会提示assignment used as truth value，但如果编译器警告级别较低，这个警告可能会被忽略。
业界有几种应对方案：
- 把常量写在左边：
if (1 == a)。这样如果不小心写成if (1 = a)，编译器会直接报错，因为1不能作为赋值的左值。这个写法叫"尤达表达式"（Yoda conditions），在开源项目里很常见。 - 在编译时使用
-Werror把警告升级为错误。 - 用静态分析工具（如cppcheck、clang-tidy）扫描代码。
我个人的看法：与其用尤达表达式这种读起来别扭的写法，不如把重点放在编译告警的规范化上。把-Wall -Wextra -Werror开起来，这类问题在编译阶段就会被拦截，代码读起来也自然得多。
3.2 &&、||、！与位运算混用的后果
条件表达式中常见的优先级陷阱还包括：
!（逻辑非）优先级高于&&和||&&优先级高于||- 位运算符
&、|、^的优先级低于关系运算符==、!=，但又高于逻辑运算符&&、||
看这个例子：
if (a & 0x0F == 0x05) { // 你以为在判断 (a & 0x0F) == 0x05 // 实际在判断 a & (0x0F == 0x05) }因为==的优先级比&高，所以0x0F == 0x05会先被计算，结果为0（假），然后整个表达式变成a & 0，结果恒为0。这个if永远不会成立。
正确的写法必须加括号：
if ((a & 0x0F) == 0x05) { // 正确 }这种问题的隐蔽性在于：不触发任何编译警告，逻辑也从语法上看不出毛病，但运行结果完全不是你想的那样。我在实际项目里见过因为这个问题导致串口通信数据校验失败的案例，排查了整整一下午才发现是优先级的问题。
3.3 短路求值：&& 和 || 的隐藏行为
C语言的&&和||都有短路求值特性：
a && b：如果a为假，b根本不会被执行，整个表达式直接为假。a || b：如果a为真，b根本不会被执行，整个表达式直接为真。
这个特性在实际项目里有非常关键的应用场景：用短路求值来保护不安全操作。
if (p != NULL && strlen(p) > 10) { // 当p为NULL时，strlen(p)不会被计算，避免了空指针解引用 }如果&&不具备短路特性，那么即使p为NULL，程序也会尝试执行strlen(p)，导致崩溃。这正是C语言选择语句在实际开发中非常实用的一个设计。
还有常见的写法：
if (fd >= 0 && read(fd, buf, n) > 0) { // 仅当fd有效时才执行read }这里利用短路特性，把"文件描述符有效性检查"和"读取操作"放在同一个if里，既简洁又安全。
强烈建议：所有在条件表达式中带有副作用的函数调用（如read、write、getchar），都要明确意识到它可能因为短路特性而不会执行。如果你确实需要它执行，就把它提前到if之前单独写。
4. 从项目角度看选择语句：状态机、菜单驱动与错误处理
讲完语法细节，我们把镜头拉远，看看选择语句在真实项目里是怎么发挥作用的。这也是热搜词里"c语言大作业开题报告"、"c语言网吧计费管理小项目"、"c语言宏多态"、"热敏电阻制作温度传感器的c语言"等词条背后真正的需求：大家不仅要学语法，更想知道怎么在项目里用起来。
4.1 状态机模式：switch-case的核心战场
在嵌入式开发、网络协议栈、UI交互逻辑中，状态机是最常见的设计模式之一。而C语言实现状态机的利器就是switch-case。
举个例子，一个简单的空调遥控器状态机：
typedef enum { STATE_POWER_OFF, STATE_IDLE, STATE_COOLING, STATE_HEATING } AirconState; AirconState state = STATE_POWER_OFF; void handle_event(Event event) { switch (state) { case STATE_POWER_OFF: if (event == EVT_POWER_ON) state = STATE_IDLE; break; case STATE_IDLE: if (event == EVT_COOL) state = STATE_COOLING; else if (event == EVT_HEAT) state = STATE_HEATING; else if (event == EVT_POWER_OFF) state = STATE_POWER_OFF; break; case STATE_COOLING: if (event == EVT_STOP) state = STATE_IDLE; else if (event == EVT_POWER_OFF) state = STATE_POWER_OFF; break; case STATE_HEATING: if (event == EVT_STOP) state = STATE_IDLE; else if (event == EVT_POWER_OFF) state = STATE_POWER_OFF; break; default: state = STATE_POWER_OFF; break; } }这种写法的核心优势是：状态迁移的逻辑集中在一个函数里，可读性和可维护性都很高。新增一个状态，只需要在枚举里加一个值，在switch里加一个case，其他状态基本不受影响。
在使用枚举作为case标签时，一定要记住前面提到的规则——case标签必须是整数常量表达式，枚举正好满足这个要求。
4.2 菜单驱动程序设计：循环+选择的经典组合
很多C语言课程设计（比如网吧计费系统、学生成绩管理系统、图书管理系统）都会用到"菜单驱动"模式。这个模式的核心结构就是"死循环 + 选择语句"。
int main(void) { int choice; while (1) { printf("===== 学生成绩管理系统 =====\n"); printf("1. 录入成绩\n"); printf("2. 查询成绩\n"); printf("3. 修改成绩\n"); printf("4. 删除成绩\n"); printf("5. 退出系统\n"); printf("请输入选项: "); scanf("%d", &choice); switch (choice) { case 1: input_scores(); break; case 2: query_scores(); break; case 3: modify_scores(); break; case 4: delete_scores(); break; case 5: printf("感谢使用，再见！\n"); return 0; default: printf("无效选项，请重新输入\n"); break; } } }这个结构几乎适用于所有"控制台菜单"型的小项目。我在这里想补充两个实际开发中很容易踩的坑：
第一个坑是scanf的输入缓冲问题。用户输入"abc"时，scanf("%d", &choice)会失败，但不消费输入，导致下一次循环再次读取同样的非法字符，形成死循环。解决办法是检查scanf的返回值，并在读取失败时清空输入缓冲：
if (scanf("%d", &choice) != 1) { while (getchar() != '\n'); // 清空缓冲区 printf("输入无效，请重新输入\n"); continue; }第二个坑是：菜单选项的case标签值和菜单显示的选项序号必须保持一致。这是小事，但项目验收时经常因为序号对应不上被扣分。
4.3 错误处理中的选择语句：集中出口 vs 层层返回
在大型C项目中，错误处理占据很大篇幅，而选择语句在其中扮演了关键角色。
常见的有两种模式：
模式一：集中出口模式
int config_load(const char *path) { FILE *fp = fopen(path, "r"); if (fp == NULL) return ERR_OPEN_FAILED; if (fscanf(fp, "%d", &version) != 1) { fclose(fp); return ERR_PARSE_FAILED; } fclose(fp); return OK; }模式二：层层返回模式
int config_load(const char *path) { FILE *fp = fopen(path, "r"); if (fp == NULL) return ERR_OPEN_FAILED; while (fgets(line, sizeof(line), fp)) { if (parse_line(line, &config) < 0) { fclose(fp); return ERR_PARSE_FAILED; } } fclose(fp); return OK; }这里最重要的是记住：任何涉及到资源（文件、内存、锁、socket）打开成功之后，后续的所有返回路径上都要记得释放资源。这是C语言内存管理和错误处理中的难点，也是热搜词里"c语言内存管理"反复被搜索的原因。
最好的做法是在设计函数时就明确：函数头部获取的所有资源，必须在函数的所有出口释放。能用goto做统一清理的就用goto cleanup模式，这可不是什么坏品味，而是内核代码中常见的做法：
int config_load(const char *path) { FILE *fp = NULL; int ret = OK; fp = fopen(path, "r"); if (fp == NULL) return ERR_OPEN_FAILED; if (fscanf(fp, "%d", &version) != 1) { ret = ERR_PARSE_FAILED; goto cleanup; } cleanup: if (fp) fclose(fp); return ret; }这种做法把清理动作集中到一处，避免了在多个if分支里重复写fclose，也减少了漏写关闭的隐患。
5. 选择语句与循环、函数指针、宏的深层联动
选择语句从来不是孤立存在的。它常常要和其他语法结构配合使用，这个配合过程中又会产生一批新的易错点。热搜词里"c语言while和do-while区别"、"c语言回调函数详解"、"c语言宏多态"这些词条，其实都和选择语句的进阶用法有关。
5.1 循环与选择：break和continue的真实区别
很多人会把break和continue搞混，或者不清楚它们在嵌套结构中的行为。这里有个很容易记错的知识点：
break：跳出最近一层循环或switch。continue：跳过本次循环体的剩余部分，直接进入下一轮循环判断。
看这个例子：
for (int i = 0; i < 10; i++) { if (i % 2 == 0) continue; // 跳过偶数，不打印 if (i == 7) break; // 到7直接退出循环 printf("%d ", i); } // 输出: 1 3 5在while循环和do-while循环里，continue的行为略有不同：while和do-while的continue会跳到条件判断处，然后重新判断条件；for循环的continue会跳到迭代表达式（i++）执行。这个差异在实际编码中容易被忽略，尤其是在while循环里用continue，如果忘记写步进语句，会造成死循环。
int i = 0; while (i < 10) { if (i == 5) continue; // 问题来了：这里会跳过i++，导致i永远等于5，死循环 printf("%d ", i); i++; }这段代码在i等于5时，continue直接跳回条件判断，i永远不会增加，于是程序陷入死循环。这是我见过很多新手甚至一些工作一两年的同事都会踩的坑。
热搜词里"c语言while和do-while区别"被频繁搜索，说明很多人对这两者的差异还不清晰。一个简单的记忆方法：while先判断后执行，循环体可能一次都不执行；do-while先执行后判断，循环体至少执行一次。
5.2 用函数指针数组替代超长switch链
当选择分支的数量非常多（比如几十个），且每个case执行的是同类型的操作时，用switch-case会让代码变得又臭又长。此时可以考虑用函数指针数组。
typedef void (*command_handler_t)(void); void cmd_start(void) { /* ... */ } void cmd_stop(void) { /* ... */ } void cmd_reset(void) { /* ... */ } void cmd_query(void) { /* ... */ } command_handler_t handlers[] = { cmd_start, cmd_stop, cmd_reset, cmd_query }; // 使用： if (cmd_id >= 0 && cmd_id < 4) { handlers[cmd_id](); // 直接用数组下标调用，等价于一个超简switch } else { printf("未知命令\n"); }这种模式的本质是"用数组索引替代分支判断"，在编译器和解释器的实现里极其常见。它的优势不仅在于代码简洁，更在于扩展性好：新增一个命令时，只需要新增一个函数，并在数组里加一个元素，而不需要改动原有的switch结构。
不过要注意：使用函数指针数组时，边界检查是必须的。如果cmd_id越界，就会访问到数组之外的内存，导致未定义行为，甚至崩溃。这就像我在前面强调的，选择语句的判断条件里，一定要把非法输入预先拦截。
5.3 宏与选择语句配合时的括号问题
C语言中宏展开是纯文本替换，如果宏里包含选择语句或表达式，括号问题会被无限放大。
看这个经典错误：
#define SQUARE(x) x * x if (a > 0) { int y = SQUARE(a + 1); // 展开后: int y = a + 1 * a + 1; // 实际计算: a + (1 * a) + 1，完全不是 (a+1)*(a+1) }正确的写法：
#define SQUARE(x) ((x) * (x))同理，如果宏里包含整个if语句，也要注意大括号问题：
#define CHECK_AND_LOG(cond) \ do { \ if (cond) { \ log_error("check failed at %s:%d", __FILE__, __LINE__); \ } \ } while (0)这里用do { ... } while(0)包住整个宏，是为了让宏在使用时行为像一个普通语句——即使你在if后面不加{}直接写CHECK_AND_LOG(x);，它也不会因为else配对问题而出错。这个技巧在Linux内核代码中被广泛使用，我强烈建议所有写C语言的人掌握。
热搜词里"c语言宏多态"也是一个相关话题——通过宏实现编译期多态，本质也是让选择逻辑在预处理阶段就完成，避免了运行时开销。不过这类技巧的代价是可读性和可调试性下降，实际使用时需要权衡。
6. 从初学者到工程实践：选择语句的代码风格与自检清单
这部分没有新语法，但比语法更重要。选择语句写得好不好，很多时候不是"能不能运行"的问题，而是"三个月后你自己还能不能看懂"的问题。
6.1 条件表达式的可读性：布尔变量和辅助函数的价值
我经常看到这样的代码：
if ((strstr(line, "ERROR") != NULL) && (line[0] != '#') && (strlen(line) > 10)) { // 处理错误日志 }这个条件本身没错，但读起来非常累。每次都要在脑子里重新解析一遍每个子条件是什么含义。
更好的做法是，把复杂的判定逻辑提取成有名字的布尔变量或辅助函数：
int is_valid_error_line(const char *line) { return line != NULL && strstr(line, "ERROR") != NULL && line[0] != '#' && strlen(line) > 10; } // 使用处： if (is_valid_error_line(line)) { // 处理错误日志 }这不仅仅是"整洁代码"的玄学，它有几个实际好处：
- 命名即注释：
is_valid_error_line这个函数名直接说明了条件的业务含义。 - 便于测试：你可以单独写一个测试用例来验证
is_valid_error_line的各种边界情况。 - 消除重复：如果同样的条件在多个地方使用，提取函数能避免多处粘贴复制。
在C语言的语境下，条件表达式不是越短越好，而是要可读、可维护、可测试。
6.2 深层嵌套的扁平化改造
三层以上的if嵌套，是代码可读性的头号杀手。
if (a) { if (b) { if (c) { // 真正的处理逻辑 } } }这种"三明治"结构的问题在于：大脑需要同时压栈三层条件才能真正理解代码的执行路径。
有两种常用的扁平化手段：
手段一：提前返回
if (!a) return; if (!b) return; if (!c) return; // 真正的处理逻辑这种方式在函数开头做参数校验时非常常见，它把"防护性条件"和"核心逻辑"分离开，让核心逻辑不再被多层嵌套包裹。
手段二：合并条件
if (a && b && c) { // 真正的处理逻辑 }如果三个条件之间没有复杂的副作用，合并是最简单的。
判断用哪种方式，核心标准是：修改一个条件时，是否需要照顾其他条件的上下文。如果条件之间相互独立，提前返回或合并都可以；如果它们之间存在先后依赖，就需要按顺序拆分。
6.3 编写选择语句前问自己三个问题
最后一个段落，我想分享一个我在Code Review时经常问自己的三个问题，它们帮我挡掉了不少潜在bug：
- 这个条件覆盖了所有可能的输入吗？比如判断整数的正负性，有没有考虑过0？判断字符串长度，有没有考虑过NULL指针？
- 条件表达式的每个操作数类型正确吗？有没有把有符号数和无符号数混在一起比较？有没有把浮点数直接用于
==判断？ - 所有分支的出口统一吗？如果每个分支都返回不同的错误码，返回值是否在调用方被正确处理了？
第三点尤其容易被忽略。比如：
int process(int type) { if (type == 1) return 100; else if (type == 2) return 200; // 如果type是其他值，函数走到这里，没有return，返回未定义值 }这种"路径缺失"的问题，在编译器的-Wreturn-type警告下会被发现，但如果你没有开启告警，它就会成为一个极难排查的运行时bug。解决方案是每一个if-else链都显式写全所有路径，哪怕最后的路径只是一个return -1。
最后分享一个我自己调试选择语句的小技巧
如果你在调试时实在看不出if或switch哪里出了问题，我建议在条件表达式里临时加打印，把关键变量打印出来看：
if (debug) printf("a=%d, b=%d, result=%d\n", a, b, (a && b));这不是什么高深的手段，但胜在简单直接，能帮你快速缩小问题范围。我见过很多人调试选择语句时喜欢在分支里加打印，这当然也行，但把条件本身打出来往往是更高效的路径——它直接告诉你"为什么走了这个分支"而不是"走了哪个分支"。
C语言的选择语句看起来简单，但细节里的魔鬼不少。希望这篇内容能帮你把这些坑提前踩平。
