分支语句这名字听着挺唬人，什么“从入门到精通”，它本质上就是让你写的代码学会做判断。我在日常评审新人代码时，发现很多问题其实都出在这类最基础的结构上——不是说不会写 if，而是边界没想清楚、条件设计得模棱两可、分支一多就乱套。这篇文章就围绕分支语句好好捋一遍，从最原始的 if-else 讲到 switch、三目运算符，再到后期我会踩过的那些坑和排查思路，希望对正卡在“会写”和“写好”之间的朋友有帮助。

1. 分支语句到底在解决什么问题

1.1 代码的岔路口：从生活决策到程序判断

先记住一句话：程序里的所有逻辑，最终都可以拆成三种结构——顺序、分支、循环。顺序就是从上往下逐行执行；循环是反复执行某段代码；分支则是在某个节点进行判断，根据条件结果走向不同的代码路径。绝大多数业务逻辑的“灵魂”都在分支上，没有判断能力，程序只是流水线，有了判断能力，才叫会思考的工具。

用一个非常普通的生活场景来比喻：“到底要不要带伞出门”。

• 如果外面下雨（条件），带伞（动作A）；
• 否则（条件不成立），空手出门（动作B）。

这就是一个典型的分支判断。放在代码里，这样一个逻辑的标准表达就是：

if (isRaining) { bringUmbrella(); } else { goOutEmptyHanded(); }

看，没有多复杂。分支语句的核心，就是根据某个条件表达式的布尔结果（真或假），决定程序的执行路径。这里的isRaining是一个布尔值，为真执行花括号里的动作A，为假执行else后面的动作B。

很多新手一看这语法觉得太简单了，转头就去写循环、写函数。但根据我的经验，基础不牢，后面绝对会出问题。分支语句不是什么高深概念，但它是一切业务逻辑的容器。登录判断、权限校验、数据合法性校验、页面跳转逻辑，底层全是 if-else 的堆叠。你如果连条件都设计不好，后面怎么搭房子？

1.2 布尔表达式才是 if 的真正灵魂

写 if 很容易，难的是写对 if 后面的那个条件表达式。if后面跟的其实是“能不能算出布尔值”的东西。布尔值只有两个：true或者false，对应真和假。

新手最常犯的一个错误，是搞混赋值和相等判断。举个例子：

if (x = 5) { // ... }

在不少语言中，单个等号是赋值，不是判断相等。这个表达式多数情况下是把5赋给x，然后整个表达式的值变成5（在某些语言里，非零被当作true），最终结果就是无论x之前是什么，这段逻辑都会走进去。这是一种奇妙的“隐形bug”，因为语法不报错，逻辑也“偶尔正确”，你根本不知道问题出在哪。正确写法应该是：

if (x === 5) { // ... }

这里我用的是相当于“严格相等”的写法===。有些语言是==判断相等，不同语言有细微区别，但共同点是：if后面跟的一定是比较式或布尔变量，而不是“赋值动作”。

除了相等判断，还有一大类比较运算：大于、小于、大于等于、小于等于、不等于。这些符号在数学课上就见过，放到代码里唯一要注意的是不要把>=写成=>之类，语法直接报错倒是小事，最怕的是拼写合法但含义变了，比如把!=写成了!==（某些语言中含义不同）。

逻辑运算符也是条件表达式的常客：&&表示且，||表示或，!表示取反。三个放一起，能组合出非常复杂的判断条件，例如：

if ((age >= 18 && isStudent) || !isBlocked) { // ... }

读法就是：当“年龄不小于18岁并且是学生”，或者“没有被封禁”时，执行某个动作。这样的组合表达式，在业务代码里几乎天天出现。写这种组合条件的时候，我强烈建议用括号把各个子条件包起来，既避免优先级问题，也是在告诉读代码的人“我这里的逻辑单元从哪开始到哪结束”。

2. 从 if 到 if-else：搭配起来才是完整判断

2.1 if-else 不是可有可无的补充

说句实在话，我一直觉得“只写 if 不写 else”是很多初学者一个相当隐蔽的坏习惯。不是说不写 else 一定不对，而是你需要明确知道“不写 else 意味着什么”——意味着当条件不成立时，程序什么都不做。

举个例子：用户登录时，密码正确（if）就跳转到首页。如果密码错误呢？如果不写else，程序就继续往下走，可能出现页面直接白屏、接口报错但前端无感知这种诡异问题。

所以业务逻辑里，该给的反馈一定要给：

if (password === storedPassword) { redirectToHome(); } else { showError("密码错误，请重试"); }

这是分支语句最基础也最标准的形态：两个分支，互斥，非此即彼。if 条件满足走上面，不满足走下面。没有第三种状态。

有时候我会问身边的人，else 这个词是什么意思？它本身就是“否则”“不然”的意思。写代码的时候，你脑子里应该时刻有这么一根弦：所有 if 背后都有一个潜在的“否则”，你自己得决定，这个“否则”是不需要处理，还是必须处理但被漏掉了。被漏掉的也会非常危险。

2.2 else if：一件事有多种结局

现实中的判断可不止两种情况。比如成绩评级：90分以上优秀，80分以上良好，60分以上及格，以下不及格。四个等级，怎么设计分支？

比较直白的写法：

if (score >= 90) { grade = "优秀"; } else if (score >= 80) { grade = "良好"; } else if (score >= 60) { grade = "及格"; } else { grade = "不及格"; }

这个结构，其实就是“else if”分支链条。注意它执行的顺序是先判断第一个条件，如果不成立，再判断下一个，每个新条件都隐含了“前面的条件都不成立”，因此这里的逻辑等价于“分数大于等于90 到 分数大于等于80到”这样逐层筛下去。

在代码评审中，这种连续 else-if 是我看得最多、也最有感觉的模式之一。它直观、易维护、好调试，非常适合不超过四五个分支的判断场景。但你要清楚顺序的影响：如果把score >= 80放在score >= 90前面，会出现什么结果？90分的人先进去第一个满足的条件，直接评级为“良好”，永远不会走到优秀那个分支。所以这种多级判断的先后顺序，是一定要反复确认的。

2.3 边界条件：判断词的临界区域

写分支语句最容易出 bug 的地方，还不是复杂逻辑，而是边界。边界就是每个条件判断的临界值，比如成绩恰好是90分、年龄恰好是18岁。

这里有一个经典但要反复强调的例子：判断“成年”通常写作age >= 18，这是把18岁本人归为成年。如果写作age > 18，那18岁生日那天就会出问题。再比如会员有效期，“小于等于结束日期”和“小于结束日期”一字之差，可能导致用户付了费却提前一天看不了内容。

处理边界有一条比较实用的经验：把边界值单独摘出来想一遍。每写完一个条件，先自问：这个值等于边界时，走哪个分支？小于时走哪个？大于时走哪个？连续问三遍，大多数边界问题能自己暴露出来。

还有一个常见场景是浮点数比较，比如折扣计算。0.1 + 0.2在计算机里并不严格等于0.3，而是0.30000000000000004。如果直接写成：

if (total - discount === targetPrice) { // 可能永远进不来 }

那很可能等不到相等的一天。处理方式一般有两种：一是比较差值绝对值是否小于某个极小的数，二是把浮点数先转成整数（比如把元转成分）再比较。这个坑很多工作两三年的同事都踩过，我特意把它记在分支话题中，因为判断条件设计得再完美，参与比较的数据本身不可靠，结果也是一场空。

3. 分支语句最容易踩的 5 个坑

3.1 悬空 else：一个让人啼笑皆非的经典错误

写嵌套 if 的时候，有个非常经典的问题，叫“悬空else”。看下面这段代码：

if (a) if (b) println("A and B"); else println("Not B");

你可能会觉得else是跟第一个if (a)配对的，但实际上，else是和它最近的、没有else的if配对，也就是if (b)。所以这段代码的真实逻辑是：

if (a) { if (b) { println("A and B"); } else { println("Not B"); } }

也就是说，当a为false时，什么都不输出。可读代码时如果误以为是前一种配对，你就会觉得逻辑完全错了。

这个坑在几乎所有支持 else 的编程语言中都能遇到。避免的办法极其简单：花括号不要省。哪怕if里面只有一行代码，也给它加上花括号。我见过太多因为省花括号引发的低级线上事故了，一行代码看起来简洁，背后是逻辑隐患。

3.2 条件赋值陷阱：循环里隐藏的“假条件”

再说一个隐蔽的小坑。写循环的时候，有人喜欢做这种“合并操作”：

while ((line = readLine()) != null) { // ... }

在某些语言中这写法是合法的：先赋值，再比较。可如果写得不够小心，或者语言规则不同，就会出现所有行都能读到但跟null比较的却是“赋值之后的值”的问题。抛开语法细节不谈，这种把赋值嵌入布尔表达式内部的做法，代码可读性极差。我见过某位同事为了一行代码的“简洁”把自己套进去——后来排查了一个下午，当时都没想到是这个隐式赋值带来的影响。

如果你非要写，也得在不同语言自己的规范下确认是否可靠。但我的建议是：别玩这种花活，按部就班写成两句：

line = readLine(); while (line != null) { // ... line = readLine(); }

分支条件和赋值动作严格分离，才是长期好维护的模式。这个原则在if、while、for等所有条件场景下都适用。

3.3 空值判断：最常见的运行时炸弹

分支语句写的多，有一个判断几乎天天都要写：判断某个值是不是空的、是不是还没定义。很多语言的运行时报错有一半以上都和“访问了某个不存在的属性”有关——说白了就是没做空值判断。

常见的初阶写法是这样：

if (user && user.address) { // 使用 user.address.city }

这写法已经不错了，先判断对象本身存在，再判断它的属性存在。但如果类属性再深一层，就要层层嵌套：

if (user && user.address && user.address.city) { // ... }

这种层层叠叠的条件就是典型的大坑前身——代码臃肿、容易漏判、维护起来相当费神。有的语言提供了可选链运算符（比如user?.address?.city），有的语言则要靠工具类方法或异常捕获来兜底。

不管用哪种方式，核心原则都是一样的：访问一个“可能为空”的对象前，先想清楚空的情况要怎么办。是直接跳过，还是给默认值，还是报错后走另一个分支。认真对待空值判断，你代码的稳定性会立刻上一个档次。

3.4 防止用力过猛的分支范围

还有一种情况比较有意思：条件本身太宽泛，把不该进来的数据也纳入了。比如判断字符串是否包含某个子串，而你真正想判断的是“等于”：

if (status.includes('成功')) { // 会误伤"部分成功" }

这种问题主要出在业务口径不够精确。为了防止这类问题，我的习惯是：在写条件之前，先把不想匹配的反例列出来。比如我说“判断是否成功”，那你至少应该告诉我：失败算什么？“处理中”算不算？“部分成功”算不算？都不说清楚，分支就是想当然的。

其实做代码评审时我看的最多的也是这个问题：条件不是语法错了，而是语义边界模糊。所以我会在下面章节专门讲怎么把分支逻辑整理得更清晰。

3.5 短路求值的副作用

最后提一个“只有老手才深有体会”的坑：短路求值。所谓短路，就是A && B中，如果A已经是false，那B根本不会执行（因为不管B是什么，结果都是false）；同理，如果A为true，在A || B中，B也不会执行（结果为true）。

这个机制本身是为了性能优化而设计的，但在特定场景下却会成为隐形杀手的来源。看例子：

if (file != null && file.size > 0) { // ... }

如果file是null呢？短路起作用，file.size不会被访问，于是不会有空指针异常。这是短路最经典的正确用法：前一个条件保护后一个条件。但反过来，如果你把有副作用的条件放在后面，就会出现“有时候执行了有时候不执行”的诡异情况。

比如，某个函数调用会修改全局状态：

if (isValid && updateCounter()) { // ... }

当isValid为false时，updateCounter不会被调用，计数器不会更新，但如果你以为它会更新而去依赖它，bug就这么出现了。所以这里有一条经验：不要在布尔表达式里放有副作用的调用——除非你有100%的把握，否则这种代码迟早坑到自己。

4. 复杂条件下的多分支利器：switch 语句

4.1 switch 与 if-else 如何选择

多分支场景里，除了连续 else-if，你可能还听说过另一个结构：switch。它的语法大概是：

switch (code) { case 0: handleZero(); break; case 1: handleOne(); break; default: handleUnknown(); break; }

读法也很直白：拿变量code去跟每个case后面的值比对，匹配上了，就执行对应的代码块，直到遇到break才跳出整个switch；如果所有的 case 都不匹配，就走default（默认分支）。

那什么时候用 switch 比 if-else if 更合适？我个人的经验标准是：判断的目标是一个离散的、明确的变量值，且分支数量不少于三个的时候，switch 的阅读体验明显更好。比如订单状态、渠道编号、错误码、星期几，这些场景天然适合 switch。

反过来，如果分支条件是范围判断，比如价格区间、成绩等级，那就别硬套 switch。switch 在绝大多数语言里支持的是相等比较，做不了“大于”“小于”判断（也有方言能做到，但语义不统一），这时候老老实实写 else-if 更清晰。

下面给一份简化的对比表：

真正在选择的时候，性能几乎可以忽略。现代语言的编译器都会把代码优化得很好。更重要的一点是语义清晰，你想表达什么场景就用什么结构。

4.2 穿透与 default：两个必须讲清的概念

switch 有一个很困扰新手的机制：case 穿透。稍微简单理解一下：当某个 case 匹配后，如果这个 case 内部没有 break 或 return 中止往下执行，程序就会接着执行下一个 case 的代码，而不会自动停在当前 case 的边界。这就是穿透。

穿透用好了是好东西。比如一年有12个月，想区分每月的天数：

switch (month) { case 2: days = 28; break; case 4: case 6: case 9: case 11: days = 30; break; default: days = 31; break; }

这里4、6、9、11故意不写任何代码，直接穿透到同一个days = 30的出口，巧妙地合并了同类场景。可一旦把 break 忘写了，后果就很怪：比如 case 1 执行完，继续执行 case 2 的逻辑，最后结果可能完全不对。

我自己早期在写类似代码时也忘过 break，当时还是一位前辈一眼看出来的，他说了一句让我印象很深的话：“你这不是bug，是传统艺能”。确实，往 switch 里漏掉 break 的案例太多太典型，坏处是即便结果碰巧对了，代码逻辑也很容易被下一个改动影响。所以现在的代码规范中，我会强制要求：所有 case 必须显式写 break、return、throw 之一；故意穿透的场景必须加注释说明，比如“// 这里故意不写 break”。

default 也不可小看。它扮演的是兜底角色：当变量的值超出所有预期情况时，走到 default 进行处理。业务代码里，把未知情况静默忽略是相当危险的，我更建议在 default 中至少打一条日志或告警，方便后续发现异常取值。

4.3 switch 与 if 的边界再思考

有种情况很有意思：早期某个值只有三种状态，用 switch 干净利落。后来需求演进，状态从三个变成八个，switch 很长，也还算可控。再后来，个别的状态需要配合额外条件，比如“状态是A且金额大于100”，switch 就有点难受了——它是单变量、单值匹配，很难优雅地结合第二个判断条件。

这时候就要反思，不是 switch 不好，而是场景已经变了。一个技巧是：保留 switch 做第一层粗拆分，然后在特定 case 内部再用 if 做二次细判断。比如：

switch (status) { case 'PENDING': if (amount > 100) { needManagerApproval = true; } break; // ... }

这种组合模式既保留了 switch 的清晰结构，又满足了复杂条件。我目前在不少真实业务代码里都在用这个思路，效果比硬塞到纯 if 或纯 switch 里都好维护。

5. 三目运算符：单行判断的利器与陷阱

5.1 写一个三目就够了

前面聊的都是 if 和 switch，都是多行结构。而在很多场景下，你只是想根据条件给一个变量赋不同的值，这时候再写五六行代码就有点笨重了。所以语言里设计了三目运算符（也叫条件运算符）。

它的基本套路非常固定：

result = condition ? value1 : value2;

翻译过来就是：如果condition成立，result等于value1，否则等于value2。

举个例子：根据用户是否登录，展示不同的打招呼文案。

const greeting = isLogin ? "欢迎回来" : "请先登录";

一行搞定，简洁，逻辑直白。这是三目运算符最能体现价值的场景：简单的二选一赋值。

我在重构老代码时，经常会把这种结构从原来的 if-else 对折成三目。代码行数能少掉一半，而且不用来回扫视前后逻辑。新手别被“运算符”三个字吓住，本质上是 if-else 的语法糖。

5.2 嵌套三目：看着牛逼，维护起来想哭

然而，三目运算符有一个很大的诱惑：当二选一不够时，有人开始链式写下去，比如：

const type = a > 0 ? "正数" : a < 0 ? "负数" : "零";

这行其实是在第一个:后面又嵌了一个三目，整体形成了三选一的判断。这种写法简洁吗？确实简洁。可我看了几秒才反应过来是正负零的区分，如果条件再复杂一点，比如四五个分支呢？

const result = x > 10 ? "大" : x > 5 ? "中" : x > 0 ? "小" : "零";

这一行已经具备了某种“意识流”气质——读完需要倒推、对齐、脑补。更麻烦的是后面别人再改，往往就陆续叠加条件，最终变成一团根本没法看的代码。我是强烈不建议在代码里出现两层以上的嵌套三目的。如果分支真的多于三个，请立刻切换到 if-else 或 switch，可读性优先，不该为了一时的炫技埋雷。

我自己有一条不成文的规矩：三目只处理“是或否”的一次判断；只要出现第二个冒号，就直接重构成普通分支。

5.3 三目运算符里的“小动作”要小心

注意一个容易被忽视的小细节：三目运算符的两个分支是表达式，不是语句。这意味着你只能在里面放“算出某个值”的代码，而不能放“声明一个变量”之类的动作（部分语言允许不同写法，但语义上有约束）。

还有，如果你在三目里调用了有副作用的函数，比如发送请求、修改全局变量，那代码的可读性会变得相当差：

status = isOK ? sendRequest() : sendRequest(); // 愚蠢但存在

这种写法不仅让人迷惑，还可能触发与短路求值类似的“有时候执行、有时候不执行”的问题。所以我的第二条规矩是：三目里只放纯计算或纯取值，不塞动作。动作逻辑请老老实实写进 if-else 里。

6. 让分支语句更优雅：流程控制与代码结构

6.1 卫语句：一种让代码飞起来的写法

聊完具体语法，说一个分支语句真正的进阶心法：卫语句。这词听起来稍专业，实际描述的情景非常常见。

想象一个登录处理函数的典型代码，很多新手会把它写成这样：

if (user != null) { if (password != null) { if (password === user.password) { // 做一堆登录成功的事 } else { // 密码错误处理 } } else { // 参数缺失处理 } } else { // 用户不存在处理 }

这种层层嵌套的写法，有个名字叫“箭头代码”，一层套一层，能超过三层就让人抓狂。而卫语句的思路是：把异常或不满足主要流程的情况，提前在开头处理并返回，把主流程留在外层平铺往下。

同样逻辑换成卫语句：

if (user == null) { return "用户不存在"; } if (password == null) { return "参数缺失"; } if (password !== user.password) { return "密码错误"; } // 做一堆登录成功的事 return "登录成功";

看到了吗？每个嵌套层都变成了一个前置“守卫”，只要条件不满足，就直接返回并结束函数，不再继续往深处钻。主流程平铺在最下面，没有任何花括号，读起来神清气爽。

卫语句是让我个人觉得对代码质量提升最大的一个小技巧。它没有引入任何新功能，只是改变了组织条件的方式。但它对可读性、可维护性的帮助是肉眼可见的。在新人培养阶段，我会专门挑出这种箭头代码来演练重构，把多层的 if 全部转成卫语句，代码行数虽然差不多，但心智负担立刻轻了。

6.2 复杂判断的命名：比注释更可靠

分支写多了会有一个矛盾：业务复杂，条件本身绕不开。读代码时的痛点不只是嵌套，而是条件表达式的含义不够直观。比如：

if (user.age >= 18 && user.country === "CN" && user.vipLevel >= 2) { // ... }

这三行条件如果直接摆在业务代码里，读的人得靠猜才能知道它的业务含义。更好的做法是：把这种复杂的判断逻辑提取成一个有明确语义的函数或变量：

const canBuyLimitedItem = user.age >= 18 && user.country === "CN" && user.vipLevel >= 2; if (canBuyLimitedItem) { // ... }

或者更进一步：

function canBuyLimitedItem(user) { return user.age >= 18 && user.country === "CN" && user.vipLevel >= 2; } if (canBuyLimitedItem(user)) { // ... }

这样写之后，代码读起来几乎是人类语言：如果“用户能购买限量商品”，那么执行某个动作。条件本身的细节可以从主流程中剥离出去，让主流程保持简洁。这个技巧，我觉得比任何注释都更能表达意图，因为函数名本身就是注释，同时它还带测试性，你可以为这个函数单独写单元测试。

6.3 说到分支治理：当分支多到爆时怎么办

有时候，分支的结构本身成了问题。比如某个枚举有十种取值，每种取值对应完全不同的处理逻辑，于是 case 堆满了整个屏幕。这种情况下就要考虑更结构化的玩法：策略模式、查表法、甚至状态机。

策略模式的设计思路是用对象（或函数）的映射来替代散装 switch：

const handlers = { add: () => { /* ... */ }, remove: () => { /* ... */ }, update: () => { /* ... */ }, }; handlers[action]?.();

这样以后，新的分支对应新的对象属性加入，原有代码几乎不用改动，每个策略的内部逻辑也相互独立。这个是从“分支语句”走向“设计模式”的一道分水岭。不过我也要提醒一句：如果你的分支数量只有三五个，完全没必要引入策略模式这种间接层。代码讲究恰到好处，过度设计同样是一种负担。

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

7.1 一个实战错误排查的完整过程

有一次某个同事反馈，一段业务代码“有时候生效，有时候不生效”。去看代码，发现核心逻辑是这样的：

if (type == 1 || type == 2 && status == 1) { // 处理A }

第一眼看上去觉得没什么，但再仔细一算：因为&&的优先级比||高（大多数语言里如此），所以这段条件的真实语义是：

if (type == 1 || (type == 2 && status == 1)) { // 处理A }

也就是说，只要type等于1，无论status是什么值都会走进处理A；而type等于2时，还要看status是否为1。用户反馈的“有时候生效”马上解释得通了：他们用到的type和status组合恰好不在预期范围内。

排查过程并不复杂，真正复杂的是人的直觉先入为主。看到||和&&写在一起时，大部分人天然以为它们是平等的、从左往右算。实际上，全世界的语言设计者都规定&&优先级高于||，这一点没有变过。

我在这里给新手一个相对可靠的建议：不要依赖优先级记忆，把每个子条件都用括号包起来。上面那段代码如果一开始就写成：

if ((type == 1) || (type == 2 && status == 1)) { // 处理A }

至少读的人一眼能看出是哪种组合。等你更熟练后再去考虑是否减括号，但没必要真的省。

7.2 分支排查时的标准套路

根据我自己的经验，定位这类逻辑 bug，可以按一套固定的流程来：

1. 先把所有“输入条件”列出来。比如上面的type和status所有可能取值。
2. 画出输入的组合矩阵，或者直接在纸上列出所有情况。
3. 人为地“走查”每一组输入，对比你的预期行为和实际行为。
4. 找出第一组不一致的情况，这往往是 bug 的入口。
5. 结合代码逐行确认，是不是优先级、边界、空值或 etc. 导致的。

一套流程走完，大多数分支逻辑问题都能水落石出。

还有一个直观的小技巧：如果知道是哪个条件表达式有问题，可以用临时打印的手段把它打出来看。比如在判断前加一行日志，把type、status、以及完整表达式的计算结果全部输出。跟踪几次，问题点通常一下就暴露了。不要小看打印调试，老手也会用，只是用得更精准而已。

7.3 常见问题速查

这张表里的问题，我几乎都亲眼见过不止一次。排查步骤其实没有太多玄学，扎实地读懂条件、明确边界、做好日志，绝大多数都能解。

7.4 测试是排查的最好防线

聊到排查，就不得不提测试。写分支语句的人，最应该问自己的问题是：我写的每个分支都被验证过了吗？如果没有，光靠静态看代码，很容易漏掉思考盲区。

面对分支逻辑，我的习惯是：在本地至少构造几个“边界用例”，手动走一遍，确认每一个条件都覆盖到。稍微有一点经验之后，可以去学“分支覆盖”这个概念——测试中要尽可能让每个分支的每个方向都执行到。

举一个简单例子，你写了if (x > 0)，那至少要测两种情况：x = 1（进入分支）和x = -1（不进入分支）。这其实就是分支测试最朴素的理解。分支语句并不复杂，但分支的穷举组合是爆炸性增长的，所以测试用例的设计很关键。但那是后话，先清楚一个事实：每个 if 都有一个 true 分支和一个 false 分支，都不能漏。

8. 一些个人体会

这么多年下来，分支语句不是我工作中最亮眼的部分，却是遇到问题最多、翻车频率最高的部分。每次线上出点小毛病，查来查去，经常是哪个 if 条件写反了、哪个边界忘了考虑、哪个 else 忘记了。我的经验是：写分支的时间通常占比不高，但思考分支的时间应该占很高。在动手写 if 之前，先在脑子里跑几遍输入组合，把条件和边界想透，然后再落笔，这样能省下太多后面排查的功夫。

还有一个感受想分享：很多人觉得“从入门到精通”是个很宏大的事，非得掌握一堆复杂设计模式才算。其实精通往往意味着把最简单的东西理解到极致。分支语句这关如果过得扎实，后面再去理解函数、模块化、设计模式，都会顺手很多。因为后面所有的东西，都是在不断组织这段“判断逻辑”。

写到最后，分享一个我一直在用的习惯：完成一段分支逻辑后，我会刻意“反向审查”一遍——把所有条件临时改成相反的值，看看是不是会出现明显不合理的路径。别看这动作简单，它真的帮我抓住过好多次隐蔽的错误。你也可以试试，在真实项目里养成这个习惯会受益很多。