★ FEATURED ARTICLE 1. 先把控制结构的位置摆正很多人学Python上来就刷语法、背列表推导式反而把控制结构当成“会写if和for就行”的边角料。我见过不少开发者在业务代码里写出三层嵌套的for循环或者用一串布尔变量硬扛状态判断最后逻辑乱到没人敢改。说句实在话控制结构才是一个程序真正的骨架变量和函数是血肉但程序往哪个方向走、什么时候走、走几步全是控制结构说了算。控制结构说白了就三大类分支、循环、异常流转。分支决定“走哪条路”循环决定“重复走多久”异常流转决定“中途出了岔子怎么办”。很多人觉得自己会if、会用while但真到写一个带状态机的爬虫、或者写一个需要重试机制的数据采集脚本就发现写出来的代码黏黏糊糊一会儿break一会儿return一会儿continue一会儿flag改着改着就失控了。原因不是语法不熟而是对控制结构的适用边界没有想清楚。这篇是我在实际项目里反复踩坑后整理出来的总结面向的是已经会写基本语法、但想把代码写得更干净的朋友。我不打算把官方文档抄一遍而是把每个结构放在真实场景里看什么时候用它为什么用它不用它会有什么代价。建议你带着自己项目里的困惑来读比如“这个循环为什么不退出”“这段分支能不能简化”“try和if到底怎么分工”读完应该会有不少对应上的地方。2. 把根扎稳if分支的写法比你想的更讲究2.1 分支的本质是缩小可能性空间我在代码评审里最常看到的问题不是不会写if而是把if写成了一堵墙。什么叫墙就是每个分支里塞了二三十行业务代码分支之间还有互相赋值的关系最后整个函数拉出来一看谁改谁怕。分支的本质是缩小可能性空间。程序执行到这里前面可能有五种状态你在if里做的其实是“问一个问题把五种状态收敛成两种”再层层递进。好的分支写法读起来应该像在做一个选择题每一层都在丢弃无效答案而不是在创造新答案。举个例子一个订单系统的退款逻辑先要判断订单存不存在再判断当前状态能不能退再判断金额是否在可退范围内。很多人一上来就写if state paid and amount total:一把梭把所有条件压在一行里。看着简单但后面需求一变比如“预售订单白天下单晚上才能退”你就得在这行里继续加条件最后变成八个and连在一起的庞然大物。我推荐的做法是逆向排除。先判断最常见的异常情况用return或raise把不符合条件的路径尽早截断只留主干的正常流程往下走。这种写法叫guard clause中文一般翻译成卫语句。它最大的好处是让主流程保持线性读代码的人不用一路记住各种条件的组合。def process_refund(order_id, amount): order find_order(order_id) if order is None: raise OrderNotFoundError(order_id) if order.state not in (paid, partial_refunded): raise InvalidStateError(order_id, order.state) if amount 0 or amount order.refundable_amount: raise InvalidAmountError(order_id, amount) # 主流程可以线性地往下走 do_refund(order, amount)每个if都在入口附近完成一次“过滤”到真正开始处理业务的时候前置条件已经全部满足。我自己的经验是函数体超过三四个嵌套if的时候就该停下来想想是不是该用卫语句或者提函数了。2.2 elif不是if的堆叠是决策链的表达elif大概是初学者最先接触的多路选择结构但很多人只是把多个独立的if写成了elif的样式并没有真正理解它的语义价值。从一个只有if没有elif的写法说起。假设我们要对分数做评级90分以上是A80到89是B70到79是C60到69是D其余是F。# 错误示范五个if同时判断 if score 90: grade A if score 80: grade B if score 70: grade C if score 60: grade D if score 60: grade F这段代码是能跑的但90分以上的成绩会把所有if都过一遍最后一次赋值覆盖掉前几次的结果最终是F。要在测试里这绝对会翻车。elif的意义就在于“互斥”一旦某个条件成立后续的所有分支都不会再被求值这不仅仅是效率问题更是消除副作用的保证。写多路分支有一点我的个人习惯从苛刻的条件往宽松的条件排列。比如上面的例子先判断90再判断80后面依次递推最后else兜底。反过来写也可以但容易漏掉中间态。还有一个小技巧是区间判断可以用链式比较Python支持连续比较比如if 80 score 90:比if score 80 and score 90更贴近人的自然语言也更不容易写错边界。2.3 分支结构的真相不要轻视elseelse是分支里最容易被忽略、也最容易埋雷的部分。我自己曾经在一个定时任务里漏写else结果某天数据异常时整个任务静默跳过排查了两个小时才发现是走了默认分支但没有做任何处理。写分支的时候我会强迫自己思考一个问题如果所有条件都不满足程序应该做什么答案是要么显式地处理要么显式地抛出异常要么显式地注释说明此处故意不做处理。反正不能什么都不写就让它滑过去。在Python里还有个特点for循环和while循环后面可以跟else这是很多其他语言没有的。这个else的语义跟if里的不同它表示“循环如果没有因为break而中断就执行else块”。刚开始容易绕晕但其实用对了很顺手。for candidate in candidate_list: if is_valid(candidate): print(found:, candidate) break else: print(no valid candidate found)这段代码比设一个found标志位干净得多。for-else帮我写过好几个查找类需求不过初学者容易误用后面我会专门讲这个坑。3. 循环的世界for、while和它们该负责的场合3.1 for循环的本质是“遍历已知集合”Python的for循环和C语言那种for(int i 0; i n; i)不完全是一个物种。Python的for是遍历迭代器只要有__iter__或者__next__方法不管是列表、字典、集合、文件对象还是生成器都能直接丢进去。这个特性有个特别实际的好处代码写起来跟业务语义同步。“遍历所有用户”就是for user in users:不是先搞个索引变量再手动自增。你不需要关心现在遍历到第几个只需要确定“还剩多少没处理”。所以很多从C系语言转过来的人写Python循环时最大的毛病是下意识地写下标循环# 不推荐的写法 for i in range(len(items)): print(items[i])这写法虽然没有错误但绕了一层还多了一次下标运算可读性更差。绝大多数场景应该直接遍历元素for item in items: print(item)如果你确实需要知道下标用枚举函数。但枚举函数也不要滥用只有在业务里真的需要索引的时候才去拿它比如比较相邻元素。另外一个容易忽略的是for遍历字典时默认遍历的是key。如果你想遍历value要么用for v in dict.values()要么用for k, v in dict.items()。有些新手在这里写错导致拿到的值不对但程序不报错属于比较隐蔽的逻辑问题。3.2 while循环是“不知道何时结束”的答案while循环和for的边界很多人分不清楚。一句话总结for解决“明确知道要遍历什么”的问题while解决“知道什么时候结束但不知道要循环多少次”的问题。最典型的场景是用户输入校验。你让用户输入一个合法邮箱用户可能输错三次也可能一次就对到底循环几次事先无法确定。用for range(3)虽然也行但次数上限写死了后面想改成“全对为止”就得重构。用while则自然得多while True: email input(请输入邮箱) if is_valid_email(email): break print(格式不正确请重新输入)这个写法用了一个while True配一个内部break。我知道很多教材喜欢说“不要用while True”但实际生产中“无限循环显式退出”是非常清晰的模式尤其是写网络重连、等待任务完成这类场景。真正的问题不是while True而是循环体内缺少明确的退出条件导致无限空转。如果担心while True过于泛滥可以把退出条件提到while语句里。比如上面的例子如果限定最多输3次tries 0 while tries 3: email input(请输入邮箱) if is_valid_email(email): break tries 1从可读性来讲带条件上限的while比while True 计数器更直白。建议你把循环条件写入while的判断中除非退出条件真的很松散需要用break来处理。3.3 循环里最容易被忽略的边界迭代时修改容器这个坑我印象太深了。当时要在一个列表里把所有符合条件的元素都加上前缀某开发者的第一版代码是在遍历的同时直接改原列表结果跑起来每隔一个元素才处理一个另一半元素被跳过了。原因在于for循环底层是靠索引推进的而遍历过程中修改列表长度会导致指针跳跃。这个问题的标准解法是遍历副本修改原件或者遍历原件收集要修改的下标等循环结束后再统一修改。# 安全做法遍历副本 for item in original_list[:]: if need_modify(item): original_list.remove(item) # 或者用列表推导式一步到位 new_list [modify(x) for x in original_list if need_modify(x)]更进一步说很多“循环里改容器”的场景本质是想做过滤或映射而这种需求完全可以交给列表推导式或者过滤函数写起来更短更不容易出错。这不是炫技是生产力。3.4 for-else的适用边界和误用提醒刚才提了for-else这里单独拿出来说是因为它是Python里“看着很爽但很容易用错”的特性之一。很多人在循环正常走完的时候需要做一件事就想到用flag或额外变量比如found False for item in items: if item.target desired: found True break if not found: do_something()这个写法当然没错但for-else让这段代码少了一个标志变量for item in items: if item.target desired: break else: do_something()逻辑是for循环正常退出也就是没有break就会进入else如果中途break了就跳过else。阅读时需要逆向理解这条规则找元素时尤其顺手。但有个我见过很多次的误用把找到目标后要做的事写在else里。去看这个场景比如“找到商品就下单”如果find到了就在循环里break下单逻辑如果误写在else里那就永远不会执行。所以用for-else时必须想清楚“else这里到底是‘没找到才走’还是‘循环结束后总是走’”语义差很大。4. 控制流改写break、continue和pass的合理姿势4.1 break是退出循环不是退出函数break的语义很简单跳出当前这一层循环。但很多人写嵌套循环时break只跳出了一层而外层还在继续导致结果跟预期不符。比如有这样一个场景二维列表里找第一个负数找到了要返回它的坐标。如果你只在内层循环break外层循环还会继续走到下一行最后根本定位不到“第一个”。正确的思路是遇到这种情况要么定义一个标志位要么直接return如果你在函数里。我一般优先return因为return更直白——我需要“拿到结果并结束整个查找过程”。def find_first_negative(matrix): for i, row in enumerate(matrix): for j, value in enumerate(row): if value 0: return i, j return None这里没有用break因为它要做的是“整个搜索停止”不是“当前行停止”。break永远只影响它所在的那一层循环这个认知非常重要。4.2 continue跳过的是本次循环不是整个循环continue适合“本轮不符合条件就跳过”的场景。比如只统计大于0的数的和total 0 for x in values: if x 0: continue total x这个等价于反着写if: total x但有时候用continue能让逻辑层次更扁平尤其当待处理的逻辑很长时先过滤掉不该处理的后面全是主线。写出高质量continue的心法只有一个不要在continue前后放太多状态。因为continue一出现就代表后面代码全部跳过如果前面已经修改了一些变量很容易出现状态不一致。所以continue前面的代码越短越好最好只是一个判断加一个continue。4.3 pass不要用pass占位它会藏住bugpass是Python里最容易被滥用的关键字之一。它表示“什么都不做”语法上需要一个语句块但逻辑上不需要执行任何操作时用。比如在接口适配里某类不需要初始化但父类定义了接口子类里写个pass表示“故意不实现”。这种情况合理。但更多时候pass被用来当占位符一个exception块里抓完异常什么都没做。这种是最危险的——因为异常被吞掉了后面出现的所有错误都会被当成“正常情况”处理排查起来非常痛苦。我的原则异常处理里的except要么记录日志要么重新抛出要么拍板“真的可以不处理”并注释理由。而普通的pass在代码评审里见了就得多问一句“这里为什么什么都不做”如果你答不上来那大概率是bug藏身点。4.4 match/casePython 3.10后的模式匹配值得一学match/case是Python 3.10加入的结构化模式匹配语法跟其他语言的switch/case有点像但功能强得多。它可以解包元组、匹配数据结构还能加if守卫。比如在解析命令的时候def parse_command(command): match command.split(): case [quit]: return bye case [add, x, y]: return int(x) int(y) case [send, *rest] if rest: return send to .join(rest) case _: return unknowncase后面可以直接写字面量、变量名解包、可变长匹配、守卫条件非常灵活。不过如果你的项目还在用旧版本Python或者团队不熟悉这个语法就不建议强行引入。工具没有绝对的好坏匹配的是团队状态和项目约束。5. 与函数协同控制结构不是孤立存在的5.1 return和break的分工是控制流清爽的关键在写业务函数时return经常承担“提前结束”的责任。一个函数里可以出现多个return只要每个return对应的都是不同的、清晰的出口状态就好。我自己偏爱“一提前多尾”的写法开头用几个卫语句return处理异常路径函数主体只保留正常流转。到尾部时可能有一个最终return返回结果偶尔视需要写第二个return返回缓存或默认值。这样每个return的语义都很干净——它不是在“退出”而是在“宣告结果”。break通常只在循环体内部使用。如果一个循环是函数的主流程循环结束后返回结果如果循环是为了找某个目标那在找到的一瞬间直接return不要再break再跳出函数多此一举。5.2 异常处理也可以看作一种控制流try/except不只是“容错机制”它本质上也是一种控制流。甚至在Python里有个重要原则叫“EAFP”——easier to ask for forgiveness than permission翻译过来是“先动手做出错再说”。与之相对的是“LBYL”——look before you leap“先检查别跳”。这两种风格的区别体现在代码里就是# LBYL风格 if os.path.exists(path): with open(path) as f: data f.read() # EAFP风格 try: with open(path) as f: data f.read() except FileNotFoundError: data 两种都有各自的适用场景。LBYL适合逻辑分支复杂、检查本身开销小的场景EAFP更适合并发环境或真正的IO操作因为文件和网络资源的状态随时可能变化“先检查再操作”反而会引入竞态漏洞。在控制结构的编排上我做的一个妥协是主流程用EAFP捕获真正的IO异常而业务状态判断则坚持“显式分支”。不要把业务规则用异常来表达比如“用户余额不足”不应该靠抛异常来控制流程而应该用if判断。异常只留给“没法用返回值表达的意外情况”。5.3 用生成器和推导式替代部分循环但别硬替换Python里有一类很特殊的控制流“隐形结构”列表推导式、生成器表达式、字典推导式。它们把“遍历收集结果”这两步压缩在一行里如果使用得当能大幅降低代码行数。squares [x * x for x in range(10)] even_squares [x * x for x in range(10) if x % 2 0]很多人喜欢拿它炫技但有些场景不适合推导式循环体内部有多个步骤、需要调试打印、有复杂分支嵌套。这个时候老老实实写for循环反而更清楚。我之前见过一个人硬把三层for循环改写成三层推导式生成一个字典看起来特别牛逼但同事们维护时根本不敢碰。衡量标准只有一个两年后的你能不能一眼读懂这段代码在干什么。如果答案是不确定就别压缩。6. 实战组合把控制结构用在一个完整需求里6.1 需求学生成绩分段统计与异常标记写一个“学生成绩分析”的模拟需求覆盖分支、while、for、break、continue、try/except看看这些结构是怎么协作的也方便你参考整套代码的组织方式。功能描述传入一个学生成绩列表名单里所有记录被视为“有效记录”要统计优秀90、及格60与不及格的人数遇到缺考的记录为异常不算入人数循环中最多输入三次试图修正异常记录最终返回统计结果。def collect_valid_scores(raw_scores): valid_scores [] invalid_records [] for record in raw_scores: score record.get(score) if score is None: invalid_records.append(record) continue # 简单做一下类型保护 try: score int(score) except (TypeError, ValueError): invalid_records.append(record) continue if score 0 or score 100: invalid_records.append(record) continue valid_scores.append(score) return valid_scores, invalid_records def analyze_grades(raw_scores): valid_scores, invalid_records collect_valid_scores(raw_scores) excellent 0 passed 0 failed 0 for score in valid_scores: if score 90: excellent 1 elif score 60: passed 1 else: failed 1 return { excellent: excellent, passed: passed, failed: failed, invalid_count: len(invalid_records), } # 最多修正三次异常记录 def retry_repair(raw_scores, repair_func, max_repair3): invalid_count count_invalid(raw_scores) repair_times 0 while invalid_count 0 and repair_times max_repair: repaired repair_func(raw_scores) if repaired 0: break repair_times 1 invalid_count count_invalid(raw_scores) return raw_scores这段代码里每类控制结构都各司其职continue用在数据清洗时跳过非法记录forelif用在分级统计whilebreak用在带次数上限的修复流程。你不需要一行一行抠关键是感受这种“每个结构都为特定语义服务”的组织方式。6.2 轮询重试场景中的组合用法真实的业务系统里重试非常常见请求第三方接口可能超时写数据库可能遇到锁冲突消息队列消费可能暂时失败。重试本质上就是控制结构的组合战场。def fetch_with_retry(url, max_retries3, base_delay1.0): last_exception None for attempt in range(max_retries): try: data fetch_data(url) return data except TimeoutError as exc: last_exception exc if attempt max_retries - 1: time.sleep(base_delay * (2 ** attempt)) # 最后一次不再sleep避免阻塞后失败还显得特别慢 raise last_exception这段有几点值得说第一for循环用range把重试次数写死在结构里while反而容易忘记递增第二异常被捕获后没有吞掉记录最后一个异常所有重试耗尽后重新抛出第三延迟时间指数退避避免对下游造成瞬时冲击。你不一定需要每次都写重试库但理解了这种控制结构组合至少遇到网络抖动时能快速写出不会让服务崩溃的兜底方案。7. 一些控制流上的血泪教训与排查技巧7.1 经典问题1循环意外提前结束先查break的层级如果你的循环“只跑了一次就停了”第一反应不是看条件而是看循环体里有没有break。尤其是when写多层循环某个break是不是比你预期多退了一层。排查的方法很简单在循环体里临时放一个打印语句每次循环输出当前索引或队头元素。看到第几次停了就知道是哪一轮触发了退出。7.2 经典问题2while条件没变化导致无限循环无限循环是最常见的事故类型也是最容易自我修复的——程序卡死CPU飙升一看就懂。但有一种隐蔽情况循环变量每次都有更新但是更新逻辑依赖一个“没有实际变化的输入源”比如从队列里读数据读了但没消费尾部不发生移动于是while condition永远为真。排查重点确认“循环条件依赖的变量”在每次循环中都会朝终止的方向变化。如果依赖的是外部输入则要检查消费动作是否正确执行。7.3 经典问题3for循环中的索引越界隐藏错误在Python里for i in range(len(items))然后访问items[i 1]最后一个轮回会越界程序直接丢异常。有些时候你以为没越界是因为条件计算偶合实际在倒数第二个就访问了不存在的元素但被忽略了。写相邻元素比较时我通常直接改用zip切片写法for current, next_item in zip(items, items[1:]): ...这样不仅安全代码也少了一半的兜底判断。7.4 常见问题速查表症状可能原因解决思路循环比预期多跑一轮while条件边界没有处理好打印每轮循环变量检查临界值循环一轮就退出break层级或continue误用确认break所在层级检查continue位置列表遍历过程中丢数据迭代时修改了正在遍历的容器遍历副本或改成推导式统一处理for-else里的代码没执行循环有break导致跳过else确认break触发分支思考是否误用elsetry里报了异常程序没反应except被吞了异常或pass占位先加日志输出再决定是否需要重新抛出程序卡死CPU跑满while无终止可能检查循环变量是否随每次迭代变化多个if都命中导致值被覆盖应该用elif的地方用了if检查条件之间是否互斥改成elif这份表不是让你背而是遇到问题的时候按图索骥。我自己写了几年Python每次排查控制流问题基本都离不开这几个方向。8. 给学习控制结构的朋友一个实用顺序如果你现在还在补基础我给的建议是不要按“if - for - while”这个顺序学而是按“问题类型”学。先学“判断”背后是数据过滤、白名单、权限校验。再学“重复”先是确定次数的重复for后是不确定次数的重复while。最后学“中断与跳出”掌握break、continue、return三者的区别之后再上手match/case和异常处理。每学一个结构都强迫自己在实际项目里找一个非用不可的场景比如写一个猜数字游戏练while和break写一个购物车计算器练分支和循环的嵌套写一个命令行菜单练无限循环加输入校验。光看语法是记不牢的一定要动手。我个人的体会是控制结构这块没有太多“高深”的东西但如果你能养成“在动手前先想清楚出口条件”的习惯后面的写代码人生会轻松很多。毕竟程序出问题十个里有八个是控制流没想明白。
阅读完成 · 觉得有帮助？
：把 settings 改到 TaoToken)
