企业官网建设流程全解析

分支结构这件事，看起来很简单，不就是个 if 吗？但我在带新手和看项目代码时发现，很多人写了两三年 Python，对分支的理解还停留在"会用 if-else"，一旦遇到复杂的判断逻辑就写得又臭又长，或者埋下一些特别隐蔽的 bug。

这篇我打算认真把 Python 分支结构从头到尾梳理一遍。不是只讲语法，而是讲清楚我们为什么要用分支、每个分支写法之间的本质区别、什么时候该用哪种方式、常见的坑有哪些。无论你是刚学 Python 的初学者，还是已经写了段时间、想回头整理基础的开发者，这篇内容都能给你一些新的视角。

1. 分支之前先搞清楚：程序里的"判断"到底是什么

很多人一上来就背 if 的语法，但我觉得先理解"判断"这件事的本源更重要。判断的本质，就是把现实世界里的决策规则翻译成计算机能执行的逻辑。你在现实中做一个决定，会有很多条件和依据，程序里的分支结构就是干这个的。

1.1 从生活场景到布尔表达式的映射

举个很简单的例子。出门前你要不要带伞，你内心其实是有一套规则的：如果天气预报说下雨，就带伞；否则就不带。这就是一个典型的双分支结构。在 Python 里，这个"天气预报说下雨"就是一个表达式，它的结果只有一个——True 或者 False。我们称之为布尔表达式。

这个映射过程特别重要，因为很多初学者的问题不是不会写 if，而是不会把现实需求拆成"条件表达式"。我曾经让学生写一个"判断某年是否闰年"的程序，很多人卡住的不是 if 写法，而是不知道怎么把闰年规则拆成人话：能被4整除但不能被100整除，或者能被400整除。这才是关键。

1.2 比较运算符是分支判断的地基

Python 里最常用的布尔表达式来自比较运算。下表帮你快速过一遍：

这里有个新手特别容易踩的坑：把==写成=。在 Python 里=是赋值，==才是比较。我见过很多人在 if 条件里写if x = 10:，结果直接语法报错。因为 Python 的赋值表达式不能出现在条件位置，这其实是 Python 在保护你，很多其他语言会允许这种误写然后静默出错，Python 直接让程序崩掉，反而好排查。

比较运算符看起来简单，但有几个地方必须额外注意。一个是浮点数比较，比如0.1 + 0.2 == 0.3这个表达式的结果是 False，因为二进制浮点数没法精确表示 0.1 和 0.2。这不是 Python 的 bug，所有主流编程语言都有这个问题。另一个是连续比较，Python 支持90 <= score <= 100这样的链式写法，它在 C 语言里是不行的，但在 Python 里是一种非常优雅的写法。

1.3 条件表达式和布尔值之间的关系

分支判断最终依赖的是bool类型。但有意思的是，Python 里很多值不需要显式转成布尔值就能参与条件判断。比如整数 0 会被认为是 False，非零整数是 True；空字符串""是 False，非空字符串是 True；空列表[]是 False，非空列表是 True；None是 False。这个特性让 Python 代码写起来非常简洁，但也带来了一些隐晦的问题，我后面会用专门一节来聊这个。

理解了这些基础之后，我们才能讨论一个问题：什么时候判断结果是不确定的？如果你把一个算术表达式当作条件，比如if 5 - 3:，Python 会先把结果算出来，然后用上一段说的规则把这个结果转成布尔值来判断。这就是所谓的"条件表达式的真值测试"。

2. 从最朴素的 if 开始：单分支、双分支与它们的代码块

现在进入正题。if 语句的语法是所有分支结构的地基，但我发现不少教程把语法讲得太轻飘飘了。我来详细拆一拆。

2.1 语法结构与缩进规则详解

最基本的 if 语句长这样：

if 条件表达式: 代码块

注意两个细节：第一，条件表达式后面必须跟一个冒号**，这是 Python 语法的一部分，不能省略；第二，下一行必须有缩进，而且同一个代码块里的缩进必须一致。Python 社区约定使用 4 个空格，不要用 Tab。

代码块的概念是理解 Python 缩进的关键。在 C 语言或 Java 里，代码块用花括号{}括起来，缩进只是为了好看；在 Python 里，缩进就是语法的一部分，它决定了一个代码块从哪里开始、在哪里结束。

如果你缩进出了问题，最常见的报错是IndentationError: expected an indented block after 'if' statement。这个错误说明 Python 在 if 后面没找到缩进的代码块。还有一种情况是IndentationError: unindent does not match any outer indentation level，这是因为你的缩进时多时少，跟上一层的缩进对不上。

我在这里给你一个非常实用的建议：编辑器里一定要开启顯示空格或制表符的功能。我见过最头疼的调试经历就是代码看起来缩进完全一致，但报缩进错误，最后发现是某个地方混入了一个 Tab。很多编辑器会把 Tab 和空格显示成不同的符号，一眼就能看出来。

再加一个双分支版本，也就是大家特别熟悉的 if-else：

import random score = random.randint(0, 100) if score >= 60: print(f"成绩 {score} 分，及格了") else: print(f"成绩 {score} 分，需要补考")

2.2 单分支和双分支各自适合什么场景

单分支if适合那种"满足条件就做，不满足就什么都不做"的场景。比如日志记录：

if error_count > 10: print("错误次数过多，需要关注！")

这种场景没有必要写 else，因为不满足条件时程序什么都不需要做。很多初学者有个毛病，不管什么 if 都要配对 else，还喜欢在 else 里写个pass。这没必要。一个空的pass只会让读者疑惑"这里是不是忘了写逻辑？"

双分支if-else则适合"非此即彼、二选一"的场景。比如判断奇偶：一个整数不是偶数就是奇数，没有第三种情况。这种用 if-else 最自然。

但这里有一个值得思考的点：你能保证现实问题都是二选一吗？不一定。分数等级划分、菜单选项处理、交通信号灯颜色，这些都是多选一。所以我们就需要 if-elif-else 结构，这在下一节展开。

2.3 一个代码块里可以有多条语句

if 后面可以跟多条语句，它们必须全部缩进。这个好理解，但我注意到有些初学者会犯一个错误，在代码块中间把缩进取消了，以为 if 块已经结束，其实后面还接着一句逻辑上属于 if 的话。比如：

if score >= 60: print("及格") print("恭喜你")

这个代码里两次 print 都会在条件满足时执行。如果把第二个 print 的缩进去掉：

if score >= 60: print("及格") print("恭喜你")

那么"恭喜你"不管成绩如何都会打印。两种效果完全不同。这种错误有时候肉眼很难发现，尤其在代码块很长的情况下。我的建议是：if 的代码块尽量短，如果超过 5 行，考虑把里面的逻辑提取成函数。这样不仅缩进不容易出错，可读性也大幅提升。

3. 当选择不只两个：if-elif-else 和多个独立 if 的根本区别

现实中的判断大多是多路选择。成绩划分等级：90 以上是 A，80 到 89 是 B，70 到 79 是 C，60 到 69 是 D，60 以下是 F。这种需求如果用嵌套 if 写，会非常痛苦，elif 就是专门为这种场景设计的。

3.1 elif 的核心逻辑：短路式多路选择

elif 是 else if 的缩写，Python 里没有直接用 else if 这个写法，而是缩写成了 elif。语法是这样的：

score = 85 if score >= 90: grade = "A" elif score >= 80: grade = "B" elif score >= 70: grade = "C" elif score >= 60: grade = "D" else: grade = "F" print(grade)

这个代码的执行流程是：从上到下依次检查每个条件，一旦某个条件为 True，就执行对应的代码块，然后整个 if-elif-else 结构就结束了，后面的所有条件不会再被检查。所以上面这个代码里，score 是 85，第一个条件score >= 90是 False，继续走；第二个条件score >= 80为 True，执行grade = "B"，然后直接跳出整个结构。它不会再去比较score >= 70了，尽管 85 也确实大于等于 70。

这个"短路"特性特别重要，它意味着你把条件顺序写反了，结果就会完全错误。比如你把等级判断写成：

if score >= 60: grade = "D" elif score >= 70: grade = "C" elif score >= 80: grade = "B" elif score >= 90: grade = "A" else: grade = "F"

那么 85 分进来，第一个条件score >= 60就为 True，直接得到 D 等级。这就是条件顺序错误导致的经典 bug。所以写 elif 链时，务必把最严格、最特殊的条件放前面，把最宽松的条件放最后。

3.2 elif 链和多个独立 if 的执行差异

这是很多人没有想清楚的点。elif 链和多个独立的 if 看起来很像，但实际上完全不同。你可以看看下面这段代码：

# 情况一：elif 链 x = 50 if x > 30: result = "偏高" elif x > 10: result = "中等" print(result) # 输出 "偏高" # 情况二：多个独立 if y = 50 if y > 30: result2 = "偏高" if y > 10: result2 = "中等" print(result2) # 输出 "中等"

第一种只有第一个条件命中，第二个条件被短路跳过。第二种两个条件都会被检查，后面那个把前面的覆盖了。所以如果你想做的是"多选一"，必须用 elif；如果你希望多个条件各自独立判断、互不影响，就用几个独立的 if。两者语义完全不同。

从性能角度讲，elif 链也通常更快，因为它找到一个命中条件后就跳过了后续一切检查；而多个独立 if 必须逐个判断完。当然这个性能差异在大多数场景下微乎其微，更重要的是语义正确性。

我在一个模拟项目中看到过这样的代码：开发者在处理订单状态时用了一连串独立 if，本来状态只应该匹配一种，结果因为条件覆盖，一下匹配了两种，后面那个把前面那个改了。这类 bug 很难排查，因为它不是崩溃，而是逻辑悄悄错掉。

3.3 顺序、边界与区间为什么值得反复推敲

elif 链把条件的顺序问题暴露得非常明显。我再强调一下：分数 60，到底算及格还是不及格？需求不同，边界定义就不同。"60 分以上"和"60 分 (含) 以上"在代码里分别是> 60和>= 60，差一个等号，结果完全不同。

写区间判断的时候，我强烈建议你用闭区间来表达。比如 80 到 89 属于 B，你可以写成：

elif 80 <= score < 90: grade = "B"

这种写法不仅符合数学直觉，更重要的是它把边界条件写得非常明确。Python 的链式比较在这里显得特别优雅。如果你用and来连接，比如elif score >= 80 and score < 90:，也可以，但视觉上不如链式写法清爽。

在实战中我还有个习惯：对于这种等级映射，与其写一长串 elif，不如用查表法。等介绍到实战部分的时候，我会再展示几种写法让你直观对比一下。

4. 嵌套不一定是坏事，但逻辑运算符能让代码更优雅

嵌套 if 就是 if 里面再套 if。很多教程一说嵌套就警告"不要嵌套太深"，但关键不是没嵌套，而是什么时候嵌套是合理的，什么时候嵌套是设计有问题的。

4.1 什么时候嵌套是自然的，什么时候该考虑重构

最自然的嵌套场景，是条件之间存在明显的先后依赖关系。比如你做一个登录系统：先要判断用户名是否存在，如果存在，再判断密码是否正确。这个"再判断"就形成了一个嵌套：

user = {"alice": "123456"} username = input("请输入用户名：") password = input("请输入密码：") if username in user: if user[username] == password: print("登录成功") else: print("密码错误") else: print("用户名不存在")

这个嵌套很自然，因为密码判断只有在用户名存在时才有意义。如果把它强行展开成扁平结构，反而会重复判断条件，让代码变得冗长。

但是，当我看到三层以上的嵌套时，就会本能地觉得不对劲。三层嵌套意味着出现了至少 8 种可能路径，人脑根本没办法快速追踪所有路径。我的经验是，一旦发现嵌套超过两层，就要问自己两个问题：能不能把内层逻辑提取成函数？能不能通过逻辑运算符把多个条件合并成一个？

4.2 用 and、or、not 把嵌套"拍扁"

逻辑运算符参与判断就是合并条件的重要手段。看这个例子：判断一个人的年龄是否属于"青年"且当前用户是否为管理员。你当然可以嵌套两成 if。但更清爽的方式：

if age >= 18 and age <= 35 and is_admin: print("允许访问")

一个 if 搞定，可读性反而更高。这里要注意and的短路特性：如果前面条件为 False，后面的条件根本不会评估。这个特性意味着，把开销较小、淘汰概率较高的判断放在前面，通常能提升一点性能。比如if user and user.is_active:，这里先判断 user 是否存在，如果不存在就直接短路，避免后面抛 AttributeError。这是很实用的写法。

or也有对应写法：只要其中一个条件为 True，值为 True，其余不评估。判断文件路径是否合法、输入是否为空，经常用到。

not更简单，就是取反。但这里有个非常常见的误区：if not user:和if user is None:并不完全等价。前者只判断 user 是否为"假值"，所以空字符串、空列表、空字典、0、False 都会命中；后者只判断是否为 None。这个差异在真实场景下会引发严重 bug，你一定得搞清楚你要判断的到底是"这个值是否存在"还是"这个值是否为 None"。

4.3 德摩根定律：让条件取反更清晰

有时候你会写出一个很长很复杂的条件，然后前面加个not。比如if not (age < 18 or age > 60):。这个意思其实是"年龄既不在 18 岁以下，也不在 60 岁以上"，也就是"年龄在 18 到 60 之间（含端点）"。但你写成这种嵌套括号加 not 的格式，别人看起来比较费劲。

这里可以用上德摩根定律来化简：not (A or B) = (not A) and (not B)，not (A and B) = (not A) or (not B)。

所以上面的判断可以写成：

if age >= 18 and age <= 60: print("符合中年范围")

一对比，是不是清晰多了？我在 code review 的时候非常喜欢抓这种地方，不是因为代码有错，而是因为条件表达式要尽量符合人的阅读习惯。

同样地，如果你发现自己要写if (条件A and 条件B) or (条件A and 条件C):这种东西，那考虑用分配律提取公共项：

if 条件A and (条件B or 条件C):

这种提取逻辑不仅让代码变短，也让逻辑关系一目了然。

5. Python 3.10 之后的分支新工具：match-case

说到分支结构，就必须聊聊 Python 3.10 引入的match-case语句了。很多初学者不太注意这个，因为老教程里没提。它表面上看很像其他语言的 switch，但实际功能要强大很多，是 Python 分支家族里一个非常值得掌握的新成员。

5.1 match-case 是什么，和 switch 有什么不同

传统 C 风格的 switch 是拿一个值与多个常量做相等匹配，而 Python 的 match-case 是结构模式匹配。差别在哪？模式匹配不只是比相等性，它可以做解包、类型判断、守卫条件，甚至递归匹配复杂的数据结构。

看一个最简单的例子：

def interpret_command(command): match command: case "start": print("开始运行") case "stop": print("停止运行") case "restart": print("重启服务") case _: print("未知命令")

这里的_是通配符，和 if-elif-else 里的 else 一个作用。注意每个 case 后面没有 break，Python 压根没有 fall-through 这种行为，执行完一个 case 分支后自动退出整个 match，这比 C 语言的 switch 安全太多了。

但 match-case 真正的威力远不止此。它可以匹配多个值：

match command: case "start" | "launch" | "go": print("开始运行")

也可以做序列解包：

point = (3, 0) match point: case (0, 0): print("原点") case (0, y): print(f"在 y 轴上，y={y}") case (x, 0): print(f"在 x 轴上，x={x}") case (x, y): print(f"坐标 ({x}, {y})")

注意这里y和x会绑定匹配到的值。这就比单纯的 if 判断灵活太多了。

5.2 用守卫条件处理更复杂的匹配

match-case 还支持在分支上加 if 条件，这叫守卫 (guard)。上一节的坐标例子不够复杂，我们看个更真实的场景：假设你要处理 HTTP 状态码，不同状态码的后续处理不同：

def handle_status(code): match code: case 200: print("请求成功") case 301 | 302 | 307 | 308: print("需要重定向") case 404 as not_found_code if code != 500 and code > 0: print(f"资源不存在，状态码 {not_found_code}") case _: print(f"其他状态码 {code}")

这个例子里的守卫就是if关键字后面的条件。只有模式匹配且守卫条件为 True 时，这个分支才算命中。如果守卫不成立，Python 会继续尝试下一个 case。

5.3 match-case 和 if-elif-else 该怎么选

说实话，if-elif-else 仍然是 Python 分支的核心，绝大多数场景下，它清晰、直观、所有 Python 程序员都熟悉。match-case 并不负责取代它，而是适合另一类场景：

• 你要匹配的是结构而不是简单值
• 你有很多个等值分支，比如命令分发、状态机转换
• 你希望在一个表达式里完成类型判断和值解包

如果只是比较大小、判断区间，老老实实用 if-elif-else。一个布尔表达式能表达的判断，你非要用 match-case 写，反而会绕远路。这部分经验是你在实际写代码时会慢慢形成的：match-case 第一次用会感觉很爽，但不要为了炫技而用它。我已经见过一些代码，把简单的大小比较写成 match-case，那真的很难读。

6. 条件表达式：用一行写判断，但别滥用

分支结构除了 if 语句，还有条件表达式，也就是大家常说的三元表达式或者三元运算符。Python 的写法很反直觉，顺序是 结果为真时的值 在前。

age = 20 status = "成年" if age >= 18 else "未成年"

它和下面的 if-else 完全等价：

if age >= 18: status = "成年" else: status = "未成年"

条件表达式的核心优势是：把赋值和一个简单的判断压缩成一行，代码更紧凑。但这里的"简单"是关键词。

6.1 条件表达式的适用场景与不适用场景

我自己的原则是：只在表达式很短的时候用条件表达式，一个条件表达式的整体结构如果横跨超过 80 个字符，或者涉及嵌套，就果断回到 if-else。你可能会看到某些人写出下面这种嵌套三元：

score = 75 result = "优秀" if score >= 90 else "良好" if score >= 80 else "及格" if score >= 60 else "不及格"

这段代码能运行，也能得到正确结果，但可读性非常差。你顺着读一遍，几秒钟才能捋清楚逻辑。这就像你写了一段只有你自己能看懂的代码，问题是你三周后自己再回来也看不懂了。

真正适合条件表达式的场景，是那些"一行小三元"：

max_num = x if x > y else y message = "成功" if is_success else "失败" discount = 0.8 if is_member else 1.0

这种一行就看明白的，用起来很舒服。如果三元表达式里再塞函数调用、再拼接字符串，那就已经越界了。我在 code review 里见到这种代码，一定会建议改成 if-else。不是说条件表达式不能用，而是可读性和可维护性优先。

6.2 条件表达式和逻辑运算符的联动：一种老手的写法

条件表达式有一个很容易被忽略的衍生用法：配合 or 和 and 实现默认值。比如：

name = input("请输入姓名：") 或 "匿名用户"

在 Python 中，or前面是假值（空字符串、None、0 等），or会返回后面的值；如果前面是真值，则返回前面的值。所以input("...") or "匿名用户"的意思就是：如果输入为空（假值），就用"匿名用户"。这个写法非常简洁，在很多真实代码里都能看到。

不过我得加个提醒：既然你兜底的是"假值"，那就代表空字符串、0 也会被兜底替换。如果你原本只希望处理 None，那就不要用or，而应该用前面提到的is None判断。这是我反复见到、而且真的在工作中踩过一次的坑，值得各位记在小本本上。

7. 实战：写一个成绩等级判断程序，从"能跑"到"耐造"

前面聊了太多理论，现在我们来亲手写个完整的程序。这个实战会一步步加需求、改 bug，最能体现分支结构在实际项目中的演进方式。

7.1 需求描述与第一版：最直白的写法

需求是：输入一个 0 到 100 的成绩，按分数输出等级：90 及以上是 A，80 到 89 是 B，70 到 79 是 C，60 到 69 是 D，60 以下是 F。

第一版，绝大多数初学者会这么写：

score = int(input("请输入成绩：")) if score >= 90: grade = "A" elif score >= 80: grade = "B" elif score >= 70: grade = "C" elif score >= 60: grade = "D" else: grade = "F" print(f"等级是 {grade}")

这完全能跑，也基本正确。但问题在哪？如果用户输入 150，或者输入 -5，程序也会给一个等级（分别是 A 和 F），这显然不合理。

7.2 第二版：加入输入合法性校验

这时你需要考虑输入校验。一个合格的程序，应该对非法输入做拦截。成绩必须先要是一个数字，而且必须在 0 到 100 之间。加校验之后，分支结构就藏在了程序里：

score_str = input("请输入成绩：") if not score_str.isdigit(): print("输入必须是非负整数") else: score = int(score_str) if score > 100: print("成绩不能大于 100") else: if score >= 90: grade = "A" elif score >= 80: grade = "B" elif score >= 70: grade = "C" elif score >= 60: grade = "D" else: grade = "F" print(f"等级是 {grade}")

你看，输入一变得正规，嵌套就自然出现了。但比第一版多了一层嵌套，这层嵌套是合理的，因为"判断成绩等级"这个动作只有在"输入合法"的前提下才有意义。不过这种写法有个明显的缺点：一旦输入非法，程序终止仍然不够友好，而且用户只能输一次，打错了就得重新运行。

7.3 第三版：用函数 + 循环重构，让结构清晰且能反复输入

第三个阶段，我会把成绩判断逻辑抽成函数，用 while 循环让用户重新输入，并且把嵌套压平一点：

def get_grade(score: int) -> str: if score >= 90: return "A" if score >= 80: return "B" if score >= 70: return "C" if score >= 60: return "D" return "F" def get_valid_score() -> int: while True: score_str = input("请输入成绩：") if not score_str.isdigit(): print("输入必须是非负整数，请重新输入。") continue score = int(score_str) if score > 100: print("成绩不能大于 100，请重新输入。") continue return score score = get_valid_score() grade = get_grade(score) print(f"等级是 {grade}")

这里我用了一种写法：get_grade 里连续写了 4 个带 return 的 if，而没有用 elif。这是因为每个分支都会 return，函数执行到 return 就结束了，后面的 if 不会再执行。这种"早返回"风格在实战中很常见，它可以让多个条件判断"扁平化"，不用再套 elif 链。

而 get_valid_score 里的 while 循环配合 continue 是另一个很实用的模式：只要输入不合法就提示并重新循环，直到拿到合法输入才 return。这就是分支和循环的联动，实战里到处都是。

7.4 扩展：如果需求改成"90 分到 100 分为 A，85 到 89 为 A-"，怎么改

最后，我们模拟一个需求变化：等级体系增加 A- 和 B+。这个改动如果用 elif 链写，得谨慎调整边界；但如果用查表法或区间判断法，改动起来就简单很多。我随手写一个表驱动写法：

grade_rules = [ (90, 101, "A"), (85, 90, "A-"), (80, 85, "B+"), (70, 80, "B"), (60, 70, "C"), (0, 60, "F"), ] def get_grade_by_table(score: int) -> str: for lower, upper, grade in grade_rules: if lower <= score < upper: return grade raise ValueError(f"成绩超出范围: {score}")

这不是用什么高深技巧，但它说明了一个很重要的点：当判断规则容易变化时，把规则数据化，把分支逻辑做成循环查表，比堆 elif 链更灵活。这种"数据驱动"的思想，在真实项目里很常见。

7.5 测试思路：边界值才是 bug 的老家

写完这个程序，我们来做测试。我发现初学者测试有个通病：只用几个随便想到的数值跑一遍，发现"能跑"就完事了。这样很容易漏掉边界 bug。

正确的思路是列一组边界测试用例：

注意，边界上是 59/60、60/61、69/70、89/90、90/100 这些相邻数值。它们最能暴露>和>=写错的问题。如果测试时专门跑一遍这组数，并且确认输出完全符合预期，你的分支逻辑才算被验证过。

最后给一个展示这组测试的简单方法：

test_cases = [(-1, "提示非法"), (0, "F"), (59, "F"), (60, "D"), (61, "D"), (69, "D"), (70, "C"), (89, "B"), (90, "A"), (100, "A"), (101, "提示非法")] for value, expected in test_cases: try: actual = get_grade(value) except ValueError: actual = "提示非法" status = "PASS" if actual == expected else "FAIL" print(f"{status}: {value} -> {actual}")

跑一下，你能很快发现边界处理是否有问题。

8. 分支结构里那些坑，全是实战总结

前面讲了很多写法，这一节专门用来踩坑。我把自己写代码和帮别人调试过程中积累的、和分支结构强相关的坑整理出来，每一条都值得你注意。

8.1 假值陷阱：空列表、空字符串、None 和 0 的区别

这是 Python 新手最容易踩的坑。前面说过，Python 里很多值都能直接当作布尔值用，比如空列表[]是 False。这意味着你写：

items = [] if items: print("有数据") else: print("没有数据")

程序会走 else 分支，因为items是空列表。这样做常常是符合预期的，而且代码也简洁。

但如果你需要区分"列表存在但为空"和"列表根本不存在"这两种情况，直接用真值判断就不够了。

# 错误示范：如果 items 可能是 None，这种方式会怎样？ if items: print("items 有内容")

当items为 None 时，它也是 False，程序同样走 else。但如果你想在 items 为 None 时单独处理，就得先做 None 检查：

if items is None: print("items 没有被初始化") elif not items: print("items 是空的") else: print("items 有内容")

这个例子告诉我们：用真值判断前，先确认你要判断的语义到底是什么。是要判断"存在与否"还是"是否为空"，这两者的条件写法完全不同。

8.2 用 is 比较 None，用 == 比较值，这个混乱会让代码出大问题

另一个高频坑是把is和==搞混。is比较的是两个对象是不是同一个对象，==比较的是两个对象的值相不相等。对于 None，官方推荐用is：if x is None:。

常见的错误是写if x == None:。这个问题在某些情况下看起来能正常工作，但实际上是个坏习惯。原因在于，==是运算符重载，某个类的__eq__方法可以被实现得非常诡异，导致x == None的结果完全不可控。而is None是身份比较，任何对象都能安全地被判断是不是 None。

同样要注意True和1的关系。在 Python 中True == 1结果是 True，但True is 1结果是 False。如果你用if x == 1去匹配一个布尔值 True，它会匹配上，这常常是出乎意料的。所以严谨的写法应该是：

• 判断真值：用if x:或if not x:
• 判断 None：用if x is None:或if x is not None:
• 比较数值：用==

8.3 浮点数判断不能直接比相等

回到前面提到的问题：0.1 + 0.2 == 0.3结果是 False。这在分支结构里会引发非常隐蔽的 bug：你认为应该走某个分支，结果程序走到了另一个分支。比如判断一个计算结果是否恰好等于某个值：

total = 0.1 + 0.2 if total == 0.3: print("相等") else: print("不相等") # 实际会走这里

解决办法是用误差范围判断，Python 里可以用 math.isclose：

import math total = 0.1 + 0.2 if math.isclose(total, 0.3, rel_tol=1e-9): print("相等") else: print("不相等")

math.isclose是专门用来做浮点比较的函数，rel_tol是相对容差。这一条你在做金额计算、物理模拟、数据统计分析时会经常用到。

8.4 变量作用域与分支的交叉问题

还有一个容易忽视的坑：在分支里给变量赋值，然后分支外马上使用。看这个代码：

if condition: value = 10 print(value) # 如果 condition 为 False，这里会报 NameError

Python 不存在块级作用域，而是函数级作用域，所以 if 里赋的变量在 if 外也能访问。但这不是说你就一定能访问到：如果条件不成立，那个赋值语句压根没执行，变量就不存在。这时你在外面用value，会抛出 UnboundLocalError 或者 NameError。

解决办法是在分支前给变量设一个默认值：

value = None if condition: value = 10 print(value)

或者是确保逻辑上每个可能路径都会给变量赋值。这个坑在嵌套分支特别深、代码很长的时候最容易被忽视。我调试过一个模块，就是某个异常路径下变量没被赋值，程序在很靠后的位置才报错，当时找原因花了很久。

说到最后，我又想起一句话，写分支结构像是在写一棵决策树。树的每一个分叉都要确保"两边都有人负责"，不能有一条路径走着走着就断了。把条件顺序、边界范围、真值语义、变量初始化这些都捋清楚，你的分支代码才会真正"耐造"。

希望这篇梳理对你有多一点帮助。如果你在调试分支逻辑时也踩过什么有趣的坑，欢迎在评论区聊聊。