★ FEATURED ARTICLE 写Python断断续续也有几年了陆陆续续带过不少刚入门的新人。我发现一个很有意思的现象很多从C、Java转过来的同学写流程控制语句时总是下意识地找大括号找不到就开始慌。其实Python的流程控制语法比大多数语言都要简单——它真正劝退新人的点藏在缩进、冒号和几个不起眼的细节里。恰好最近有不少朋友在后台问我Python基础语法怎么学最扎实借着这篇核心语法二我把流程控制这块彻底讲透把我在真实项目里踩过的坑、总结的技巧一并交代清楚。无论你是刚装好Python、还在折腾VSCode或PyCharm环境配置的新手还是写过一阵子但总觉得自己代码不够地道的半熟手这篇都适合你。1. 缩进与冒号Python流程控制的第一道门槛1.1 为什么缩进是语法的一部分而不是代码风格很多从其他语言转过来的同学第一次写Python的if语句时都会产生一个疑问为什么if下面一定要缩进不缩进行不行这就要说到Python设计哲学里一个非常核心的决策——用缩进来表达代码块。在C语言里if后面用花括号{}圈定范围缩进纯粹是为了好看不缩进代码照样跑。Python则干脆把缩进本身变成语法的一部分。同一个代码块内的语句必须有相同的缩进量解释器就靠这个来判断哪些语句属于同一个分支、同一个循环体。这不是风格问题是语法规则。违反它解释器会直接抛IndentationError。我自己的体会是这个设计其实是在帮你强迫养成好习惯。因为缩进参与语法解析你只要打开任何一个Python文件一眼就能看出哪些代码在哪个逻辑块里可读性天然有保障。坏处也很明显——如果项目里有人用Tab缩进、有人用空格缩进合并代码时就会出现代码看着对齐了但解释器认为不在一个代码块的诡异情况。注意PEP8官方推荐使用4个空格作为缩进单位。无论你多喜欢Tab键的手感在Python项目里请统一用空格。1.2 我在真实项目里遇到的缩进灾难现场说一个我刚开始带项目时真实发生的事。当时团队里有个新同事从某编辑器里粘贴了一段代码所有行开头都变成了Tab而项目其他文件全是4个空格。代码贴进去之后看起来缩进层次完全没问题编辑器里显示也是对齐的但一运行就报IndentationError: unindent does not match any outer indentation level。排查了很久才发现在某些行Tab被编辑器自动展开成了8个空格另一些行则保持了Tab字符。同一个逻辑块的代码有的行缩进是8个空格有的是一个Tab视觉上可能同样是8个空格宽解释器就认为它们不是同一个代码块。怎么解决两个办法。第一在VSCode里按下CtrlShiftP输入Convert Indentation to Spaces把整个文件的Tab统一转成空格。第二更推荐的方式——在VSCode的设置里搜索editor.insertSpaces勾选Insert spaces when pressing Tab然后editor.tabSize设为4。这样你按Tab键时编辑器会自动插入4个空格从根本上杜绝混用问题。PyCharm里则是Editor - Code Style - Python - Tabs and Indents把Indent设为4并在右下角把Tab显示成4 spaces。其实还有一种更隐蔽的情况有时候代码是从网页、PDF或者聊天工具里复制过来的复制进来的时候缩进已经被改成了全角空格。这种字符普通编辑器根本看不出来但解释器会报错。排查方式很简单在VSCode里开启Render Whitespace设置项editor.renderWhitespace设为all所有空格和Tab字符都会以灰点和箭头形式显示出来一眼就能看出哪里混入了奇怪字符。1.3 冒号到底在冒什么缩进之外Python流程控制语句还有一个视觉特征——冒号。if、for、while、def、class这些语句的行尾都有冒号很多新手容易忽略写完条件回车发现报语法错误回头一看冒号忘了。冒号的作用是告诉解释器接下来这行开始是一个新的代码块请按缩进规则解析。它背后其实反映了Python一个重要的设计取舍不靠关键字或符号去结束一个代码块而是靠缩进回归到上一级。你可能觉得这个设计啰嗦但真正常写之后会发现它极其舒服。C语言里一个复杂函数的花括号嵌套会让你数得眼花缭乱Python里缩进层次就是逻辑层次基本不会出现少写一个右花括号导致一大片代码逻辑错乱这种经典灾难。2. if/elif/else条件分支的坑与正确姿势2.1 真假值判断Python的条件比你想象的宽泛绝大多数编程语言里if后面必须接一个布尔表达式true或false。Python不一样它允许你在if后面放任意对象解释器会沿着bool()这条隐式转换路径去判断这个对象是真是假。这条规则极其重要因为新手在这个地方踩坑的概率非常高。Python中以下值在布尔上下文中全部被视为False常量False和None数值0、0.0、0j空字符串空列表[]、空元组()、空字典{}、空集合set()自定义对象中定义了__bool__()返回False或者定义了__len__()返回0除此之外的绝大多数对象都是True。这个设计最大的好处是你可以写出非常自然的判断代码。比如判断一个列表是否为空初学者可能会这样写if len(items) 0: print(有数据)而Pythonic的写法是if items: print(有数据)同理判断一个字符串是否为空# 不推荐 if name ! : print(名字不为空) # 推荐 if name: print(名字不为空)这两者的逻辑等价但后者读起来更像人话。如果items有东西、如果name非空这就是Python的truthiness机制带来的表达红利。不过要注意这有个前提是你清楚自己在判断什么。如果你原本想判断的是变量是None还是为空字符串那必须显式写if x is None和if not x这两者有本质区别——前者判断身份后者判断真假值。空字符串是FalseNone也是False但它们是两个完全不同的值。另一个高频踩坑点是和is的混淆。Python中比较的是值is比较的是内存身份对象是否是同一个。对于小整数、短字符串这种被解释器缓存的不可变对象5 is 5偶尔会返回True导致一些人误以为is就是。一旦遇到大整数或者动态拼接的字符串is的结果就变成了False于是莫名其妙的bug就出现了。我的建议是判断值用判断是不是同一个对象比如对比None用is别混着来。2.2 elif不是else if的简单缩写Python里没有其他语言那种else if关键字组合而是专门设计了elif。这一点本身没什么坑但很多人对elif的理解停留在else if缩写了这一层没有真正理解它背后的执行逻辑——短路匹配。看这个例子score 85 if score 90: grade A elif score 80: grade B elif score 70: grade C else: grade DPython解释器会从上到下依次判断每个条件。一旦某个条件为True执行对应的代码块然后整个if-elif-else链直接结束后面的elif和else都不再判断。这带来一个非常实际的优化思路条件顺序会影响性能。如果一组条件互斥你应该把最容易命中的条件放在最前面。比如一个Web接口要校验用户身份先从缓存里取数据、再从数据库取、最后才走外部接口那你应该把命中缓存这个概率最高的分支写在最前面减少无谓的条件判断。同时elif和多个独立if有本质区别。我见过有人写出下面这种代码if score 90: grade A if score 80: grade B # 注意如果score95这里会把grade又改成B两个if之间没有互斥关系都会依次执行于是后面那个条件直接覆盖了前面的结果。这是新手非常容易犯的逻辑错误——该用elif的时候用了if导致变量被多次赋值、结果被意外覆盖。我建议在任何互斥分支场景下无条件选择elif把多个if留给需要逐个独立判断的场景。2.3 三元表达式一句话条件分支的取舍Python支持条件表达式俗称三元表达式语法是a if condition else b。它在某些场景下能让代码变得简洁无比status 成年 if age 18 else 未成年但这个东西有个致命陷阱——可读性。一旦你嵌套使用代码立刻变成天书result A if score 90 else (B if score 80 else C)这种写法我极其不建议在生产代码里出现。嵌套三元表达式虽然语法上合法但读起来要一层层扒开非常反人类。我的原则是三元表达式只用于简单的两者择一一旦涉及三个及以上分支老老实实写if-elif-else。用一个可以量化的标准来判断——如果一行代码超过80个字符或者需要括号包裹才能表达清楚就别用三元。3. for循环Python里最常用的流程控制结构3.1 range的参数细节不只是三个数字range()是Python for循环里最常搭档的内置函数但它不像很多人想的那么简单。完整写法range(start, stop, step)生成的数字从start开始到stop结束前为止不包括stop本身间隔是step。这个左闭右开的设计让很多新手困惑为什么range(5)生成的是0到4而不是0到5其实这是有数学上的考虑——它可以让两个相邻range完美拼接而不重叠比如range(5)和range(5, 10)合起来正好是0到9中间没有缺口也没有重叠。几个容易踩的细节range(5)等价于range(0, 5, 1)start默认0step默认1。如果只传一个参数它代表stop传两个参数代表start和stop传三个才是完整的。少传参数时不要搞混位置。step可以为负数。range(5, 0, -1)生成[5, 4, 3, 2, 1]注意此时start必须大于stop否则循环体一次也不执行。range()返回的不是列表而是一个range对象它是一个惰性序列。这意味着它不会占大量内存——range(1000000000)并不会真的创建一个包含十亿个数字的列表。但如果你直接打印range(5)看到的是range(0, 5)而不是[0, 1, 2, 3, 4]。在实际工作中最常见的循环场景是用range(len(...))配合下标访问列表但这其实不太Pythonic。更好的方式是把迭代对象直接交给for循环# 不推荐 for i in range(len(cities)): print(cities[i]) # 推荐 for city in cities: print(city)如果需要同时拿到下标和值用enumerate()for idx, city in enumerate(cities, start1): print(f{idx}. {city})注意enumerate的第二个参数start可以指定起始下标默认是0。很多业务场景比如从1开始编号都会用到这个参数。3.2 迭代对象解包for循环真正的威力Python for循环和其他语言最大的不同在于它不是一个数字计数器而是彻底的迭代协议。你不需要下标不需要手动递增变量只要把任何可迭代对象放在in后面它就一个接一个地取出里面的元素。这个设计让Python的循环表达能力远超同类语言配合解包unpacking更是如虎添翼。同时遍历两个或多个列表用zip()names [张三, 李四, 王五] scores [88, 92, 76] for name, score in zip(names, scores): print(f{name}: {score})zip()的工作原理是并行地从每个可迭代对象中取出一个元素组合成元组。它的一个隐藏特性是以最短的迭代对象为准。如果你两个列表长度不一致zip会默默截断不报错也不提示。这在某些场景下是我们想要的比如对齐前N个元素但在另一些场景下会造成数据静默丢失。如果你需要严格校验长度一致Python 3.10之后可以用zip(strictTrue)参数一旦长度不一致直接抛ValueError。遍历字典的时候解包更是高频操作user_info {name: 张三, age: 30, city: 北京} # 遍历键 for key in user_info: print(key) # 遍历值 for value in user_info.values(): print(value) # 同时遍历键和值——这是最常用的 for key, value in user_info.items(): print(f{key}: {value})Python官方文档里特别提醒过遍历字典时不要在循环体内修改字典的大小增加或删除键。因为字典遍历依赖内部的哈希表游标改动大小后行为是未定义的可能在Python 3.12里直接报RuntimeError: dictionary changed size during iteration。如果你确实需要边遍历边删数据先拷贝一份key列表for key in list(user_info.keys()):或者用字典推导式重建一个新字典。3.3 推导式把for循环压成一行当你的循环体只是为了构建一个列表、字典或集合时Python引入了一类极其简洁的语法——推导式comprehension这是Python流程控制体系中我非常偏爱的一环。列表推导式的基本形式是[表达式 for 变量 in 可迭代对象 if 条件]# 传统写法 squares [] for i in range(1, 10): if i % 2 0: squares.append(i * i) # 推导式写法 squares [i * i for i in range(1, 10) if i % 2 0]两者的核心区别不仅在于代码行数。推导式在CPython内部有专门的优化路径执行速度通常比等效的for循环append方式快20%-30%。在大规模数据处理场景下比如从几万条日志里提取特定字段这个性能差异是很明显的。字典推导式和集合推导式同理# 字典推导式把列表变成索引字典 names [张三, 李四, 王五] name_to_id {name: idx for idx, name in enumerate(names)} # 集合推导式去重 prices [120.5, 88.0, 120.5, 66.0] unique_prices {p for p in prices}但我必须提醒一点——推导式不是万能的。如果循环体里有多个语句、有副作用比如打印日志、修改其他变量、或者循环逻辑很复杂强行塞进推导式会让代码变得极其难读。我见过一段嵌套了三层推导式的代码看了整整一个下午才理清逻辑。这里的判断标准是一行推导式能承载的逻辑复杂度是有限的超过两个for或两个if就应该写成普通循环。可读性永远优先于简洁性。4. while循环与循环控制四件套4.1 while和for的选型逻辑Python里的while循环语法很简单while 条件:条件为真就反复执行循环体直到条件变成假。但什么时候该用while、什么时候该用for很多人其实没有想清楚。我的选型逻辑非常简单如果你知道要迭代多少次且迭代对象是一组明确的数据用for如果你不知道要循环几次、需要根据回路里的条件动态决定是否继续用while。典型的使用while的场景从用户输入读取数据直到输入特定指令如quit才停止轮询某个异步任务的状态直到任务完成二分查找算法——每次循环把搜索区间减半直到区间为空游戏主循环——每一帧检查退出条件下面是一个典型的读输入直到退出的写法command while command ! quit: command input(请输入指令输入quit退出: ) # 处理指令写while循环最需要警惕的问题就是死循环——条件永远为真程序永远不停。常见的原因条件里比较的变量没有被更新或者更新逻辑写在了continue之后导致永远执行不到。我在本地调试的时候一直强调一个习惯凡是写while True:这种结构先想清楚循环体内哪一行代码最终会让break执行到。如果找不到这一行那这代码一跑就是一个死循环。4.2 break、continue、pass三个容易混淆的小角色break、continue、pass是流程控制里的三个小关键字作用完全不同混用的概率极高。break立即终止当前所在的整个循环不管循环条件是否还满足。循环体后面的代码不会执行循环直接结束。continue跳过当前这一次迭代立即进入下一轮循环。注意在while循环中遇到continue会直接跳到条件判断处在for循环中会跳到下一个元素的迭代。pass什么都不做就是个占位符。它本身不产生任何行为。网上有个经典的坑新手想在循环里跳过空值并继续写了continue但放在错误的结构里导致提前跳过了某段重要代码。我们来看正确和错误的对比data [hello, , world, ] for item in data: if not item: continue # 跳过空字符串立即处理下一个元素 print(item.upper())这个没问题。但如果有人把continue放在一个子循环内部它跳过的只是内层循环的本次迭代外层循环不受影响。很多人误以为continue会跳过整个外层循环的下一次迭代实际并不是——它只作用于离它最近的那一层循环。这个细节在嵌套循环中非常容易引发逻辑bug。pass的典型用于场景是你还没想好函数体里写什么但如果不写任何语句Python会因为函数体为空而报IndentationError。这时候可以用pass占位def send_retry_alert(retries): # TODO: 等运营把告警频次规则定下来再实现 pass4.3 被很多人低估的for-elsePython里有一个其他主流语言都没有的特性——循环语句可以带else分支我称之为「循环的临终遗言」。它的执行规则是如果循环是正常结束的没有被break中断就执行一次else分支如果循环是被break终止的else分支不执行。这个特性在实战中极其好用最常见的场景是在循环里搜索某个元素如果找到了就做一件事找不到做另一件事。传统写法是这样的found False for user in users: if user.id target_id: found True break if not found: add_user(target_id)每次都要定义一个found标志位循环结束后再判断一次。而用for-else可以写得更自然for user in users: if user.id target_id: print(找到了) break else: add_user(target_id)当整个循环遍历完都没有执行break时else里的代码就执行了相当于没找到就补录。很多C系语言的程序员看到这个会觉得不适应但掌握之后你会发现它避免了标志位变量逻辑清晰得多。不过这里有一个极其重要的陷阱如果循环体里连break都没有else分支必定执行。所以如果你写了个普通循环没带break又误加了else你可能会发现else里的代码每次都会跑一遍。我就见过有人把else当成循环结束后不管怎样都执行来用了导致业务逻辑重复执行。for-else的正确语义是循环未被中断时执行而不是循环结束后执行。没有break的循环配else除非你故意想用否则属于逻辑错误。5. match-casePython 3.10带来的流程控制新成员5.1 基本的模式匹配语法如果你用的是Python 3.10及以上版本那么流程控制家族里多了一位新成员——match-case语句。它看起来像其他语言里的switch-case但实质上完全不同。match-case做的是结构模式匹配不只是比较一个变量等于什么值还能根据数据的结构、类型和具体字段来匹配。最简单的用法def describe_status(code): match code: case 200: return OK case 404: return Not Found case 500: return Internal Server Error case _: return Unknown注意这里的case _下划线是通配符匹配任何值相当于其他语言的default。需要注意的是从上到下依次匹配一旦某个case命中就执行对应代码块并立即退出整个match不需要像C语言那样手动写break。虽然这个简单用法看起来跟switch差不多但match-case的真正威力在于解包模式匹配。它可以直接匹配一个元组的形状point (10, 20) match point: case (0, 0): print(原点) case (x, 0): print(fX轴上的点x{x}) case (0, y): print(fY轴上的点y{y}) case (x, y): print(f普通坐标点 ({x}, {y}))case (x, 0)这种写法不是简单比较元组是否等于(x, 0)而是一种模式——它绑定变量x同时强制第二个元素必须是0。这种结构性匹配让代码非常优雅。5.2 什么时候值得用match-case我个人的判断是match-case不是让你把所有if-elif链都改掉而是在特定场景下有明显优势判断一个对象的类型和结构。比如处理解析树、处理JSON数据的多种形态、实现命令模式CLI指令分发。分支条件非常多。超过四五个elif的条件链用match-case会让结构更清晰。需要解包和命名的场景。case语句还支持用if加守卫条件def classify_number(num): match num: case n if n 0: return 负数 case 0: return 零 case n if n 10: return 一位数 case n if n 100: return 两位数 case _: return 大数如果你在用Python 3.9或更早版本match-case会直接导致语法错误。老项目升级Python版本之前建议先用这个特性写个小demo验证环境没问题再逐步把条件链改造成match-case。我见过有人把线上代码切到match-case后直接SyntaxError整个服务起不来就是因为服务器上Python版本还是3.8。流程控制语法看着简单但版本兼容性一点都不能马虎。6. 真实项目踩坑记录与排查复盘6.1 案例一循环中修改列表元素的诡异结果这个坑我印象很深。当时在做一个数据处理任务需要对列表里的每个元素做清洗如果元素违反规则就把它从列表中删除。我的第一版代码长这样items [1, 2, 3, 4, 5, 6] for item in items: if item % 2 0: items.remove(item) print(items)我期望输出的是所有偶数都被删掉剩下[1, 3, 5]。但实际输出是[1, 3, 5]不实际输出是[1, 3, 5]之外的诡异结果——具体是[1, 3, 5]我再算一下。乖乖跑一遍遍历索引0值为1不删索引1值为2删掉2列表变成[1, 3, 4, 5, 6]索引2此时是4原来的3被挤到了索引1的位置4是偶数删掉列表变成[1, 3, 5, 6]索引3是6删掉变成[1, 3, 5]。这个例子凑巧删对了。但我把数据换一下就看出来了items [1, 2, 3, 4, 5, 6, 8] for item in items: if item % 2 0: items.remove(item) print(items) # 得到 [1, 3, 5, 8]8为什么没被删因为遍历到8的时候8已经因为前面的删除操作被移动到了索引6而循环早就走完了。这个问题的根源是在for循环遍历列表的同时修改列表长度迭代器使用的下标和列表实际元素发生了错位。排查思路复盘先打印每一步的列表内容和当前遍历到的值发现下标和值对不上。意识到for item in items本质上是在内部维护了一个整数下标每次迭代下标加1然后按下标取值。remove操作把后续元素往前挪导致有些元素被跳过。正确解法是改用列表推导式重建一个新列表items [item for item in items if item % 2 ! 0]或者如果你必须在原列表上操作先拷贝一份再迭代for item in list(items): if item % 2 0: items.remove(item)这个坑的教训是凡是迭代集合时想同时修改集合删除或增加元素必须拷贝一份或者改用推导式/新建列表的方式。这个规则适用于列表、字典、集合不仅限于for循环while循环里用下标操作也要格外小心。6.2 案例二短路逻辑救了你但你可能不知道有一次用Python写一个配置校验函数需要判断一个配置项是否存在且取值合法。第一版代码if config.get(timeout) 0: print(timeout合法)这段代码在某些配置下直接抛TypeError: not supported between instances of NoneType and int。原因很简单config.get(timeout)在键不存在时返回NoneNone 0在Python里不能运算。排查的过程不复杂但暴露出的问题挺典型很多新手不知道Python的and、or有短路求值的特性。a and b在a为假时直接返回a根本不会去计算ba or b在a为真时直接返回a不去计算b。正确写法应该把存在性判断放在前面充分利用短路if config.get(timeout) is not None and config.get(timeout) 0: print(timeout合法)更Pythonic的写法是利用真值判断比较# 需要先取出值避免重复调用get timeout config.get(timeout) if timeout and timeout 0: print(timeout合法)这里if timeout已经利用了我们第2节讲的真假值判断——None是假0也是假。要注意的是如果你的合法值可能为0这种写法会把0也排除掉这是另一个隐性问题。所以业务上真值可能为0时要改回is not None判断。短路求值还带来一个非常实用的技巧Python没有其他语言的空值合并运算符但可以用or来模拟默认值效果username input_name or 游客当input_name为空字符串假值时整个表达式返回游客。这个写法在配置读取场景里用得非常广泛但要注意如果input_name可能为0或False这类合法值不能这么写。6.3 案例三for-else的else在我以为不会触发时触发了这是我亲身经历的一次线上bug。当时有一段代码需要在订单列表里查找特定订单找到就更新状态没找到就创建一个新订单。我当时用了for-elsefor order in orders: if order.id new_order_id: update_order(order) break else: create_order(new_order_id)这段代码有个隐患如果orders列表本身是空的for循环一次都不执行但这不算被break中断所以else分支照样会执行——于是创建了一个新订单。这在业务上可能完全正确也可能不是你想要的行为。我那次遇到的实际情况是上游系统偶尔会传一个空订单列表过来结果系统每次都走create_order把本来应该判失败的操作变成了创建新订单数据里出现了大量重复的单子。排查链路是这样的先看日志发现某个接口频繁执行创建订单操作。翻代码看到for-else逻辑第一反应觉得没找到才创建逻辑没问题。后来打印orders长度才发现列表为空时for循环体根本没进过else直接执行。这个坑的本质是for-else中的else不关心循环体是否执行过哪怕一次只关心循环是否被break终止。空列表遍历也会触发else。正确的修复方式是显式判断列表是否为空if not orders: # 空列表按预定逻辑处理可能告警可能直接返回失败 create_order(new_order_id) elif any(order.id new_order_id for order in orders): for order in orders: if order.id new_order_id: update_order(order) break else: create_order(new_order_id)这段修复代码还引入了一个重要的生成器函数any()它可以用来替代手写for循环找元素的常见场景。类似地all()用来判断是否所有元素满足条件写出来比for循环简洁许多。这类隐藏的流程控制工具建议每个Python学习者在基础语法之外专门过一遍。7. 几个延续思考的进阶方向如果你把前面这些内容都消化了并且在自己的环境里把代码都跑了一遍那么流程控制的基础已经打得很扎实了。接下来你想进阶的话我建议按这个顺序延伸迭代器与生成器。for循环背后其实是迭代协议理解__iter__和__next__能帮你明白为什么所有可迭代对象都能被for遍历。生成器函数里的yield能写出惰性求值的流程控制逻辑在处理超大文件、无限数据流时非常重要。异常处理作为流程控制。Python的try-except-else-finally结构本质上也是一种流程控制它决定了程序在出错时走哪条路。尤其是try-except-else——try没有异常时走else这个和for-else有异曲同工之妙很多新手同样会搞混。上下文管理器。with语句里的__enter__和__exit__控制了资源申请和释放的流程网络连接、文件读写都用它这是Python资源管理的标准解法。并发场景下的循环控制。如果用asyncio写协程async for可以异步遍历数据流。这时候break、continue的语义虽然在但执行时序要放在事件循环的框架里重新理解。Python的协程相关热词搜得越来越多这条线值得走。不过你有精力弄这块之前先确保自己同步、同步异常处理都过关了再碰异步循环不然极其容易绕晕。我个人的体会是流程控制是任何编程语言的核心骨架学Python语法不把这一块吃透后面的数据结构、函数式编程、面向对象都会摇摇欲坠。但反过来只要这块扎扎实实过了你去看任何Python项目源码至少能顺畅地读下来——知道每一段代码在什么条件下执行、在哪个循环里跑。这个能力比记住几个API重要得多。
阅读完成 · 觉得有帮助？
