寫Python斷斷續(xù)續(xù)也有幾年了陸陸續(xù)續(xù)帶過不少剛?cè)腴T的新人。我發(fā)現(xiàn)一個很有意思的現(xiàn)象很多從C、Java轉(zhuǎn)過來的同學寫流程控制語句時總是下意識地找大括號找不到就開始慌。其實Python的流程控制語法比大多數(shù)語言都要簡單——它真正勸退新人的點藏在縮進、冒號和幾個不起眼的細節(jié)里。恰好最近有不少朋友在后臺問我Python基礎語法怎么學最扎實借著這篇核心語法二我把流程控制這塊徹底講透把我在真實項目里踩過的坑、總結(jié)的技巧一并交代清楚。無論你是剛裝好Python、還在折騰VSCode或PyCharm環(huán)境配置的新手還是寫過一陣子但總覺得自己代碼不夠地道的半熟手這篇都適合你。1. 縮進與冒號Python流程控制的第一道門檻1.1 為什么縮進是語法的一部分而不是代碼風格很多從其他語言轉(zhuǎn)過來的同學第一次寫Python的if語句時都會產(chǎn)生一個疑問為什么if下面一定要縮進不縮進行不行這就要說到Python設計哲學里一個非常核心的決策——用縮進來表達代碼塊。在C語言里if后面用花括號{}圈定范圍縮進純粹是為了好看不縮進代碼照樣跑。Python則干脆把縮進本身變成語法的一部分。同一個代碼塊內(nèi)的語句必須有相同的縮進量解釋器就靠這個來判斷哪些語句屬于同一個分支、同一個循環(huán)體。這不是風格問題是語法規(guī)則。違反它解釋器會直接拋IndentationError。我自己的體會是這個設計其實是在幫你強迫養(yǎng)成好習慣。因為縮進參與語法解析你只要打開任何一個Python文件一眼就能看出哪些代碼在哪個邏輯塊里可讀性天然有保障。壞處也很明顯——如果項目里有人用Tab縮進、有人用空格縮進合并代碼時就會出現(xiàn)代碼看著對齊了但解釋器認為不在一個代碼塊的詭異情況。注意PEP8官方推薦使用4個空格作為縮進單位。無論你多喜歡Tab鍵的手感在Python項目里請統(tǒng)一用空格。1.2 我在真實項目里遇到的縮進災難現(xiàn)場說一個我剛開始帶項目時真實發(fā)生的事。當時團隊里有個新同事從某編輯器里粘貼了一段代碼所有行開頭都變成了Tab而項目其他文件全是4個空格。代碼貼進去之后看起來縮進層次完全沒問題編輯器里顯示也是對齊的但一運行就報IndentationError: unindent does not match any outer indentation level。排查了很久才發(fā)現(xiàn)在某些行Tab被編輯器自動展開成了8個空格另一些行則保持了Tab字符。同一個邏輯塊的代碼有的行縮進是8個空格有的是一個Tab視覺上可能同樣是8個空格寬解釋器就認為它們不是同一個代碼塊。怎么解決兩個辦法。第一在VSCode里按下CtrlShiftP輸入Convert Indentation to Spaces把整個文件的Tab統(tǒng)一轉(zhuǎn)成空格。第二更推薦的方式——在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。其實還有一種更隱蔽的情況有時候代碼是從網(wǎng)頁、PDF或者聊天工具里復制過來的復制進來的時候縮進已經(jīng)被改成了全角空格。這種字符普通編輯器根本看不出來但解釋器會報錯。排查方式很簡單在VSCode里開啟Render Whitespace設置項editor.renderWhitespace設為all所有空格和Tab字符都會以灰點和箭頭形式顯示出來一眼就能看出哪里混入了奇怪字符。1.3 冒號到底在冒什么縮進之外Python流程控制語句還有一個視覺特征——冒號。if、for、while、def、class這些語句的行尾都有冒號很多新手容易忽略寫完條件回車發(fā)現(xiàn)報語法錯誤回頭一看冒號忘了。冒號的作用是告訴解釋器接下來這行開始是一個新的代碼塊請按縮進規(guī)則解析。它背后其實反映了Python一個重要的設計取舍不靠關(guān)鍵字或符號去結(jié)束一個代碼塊而是靠縮進回歸到上一級。你可能覺得這個設計啰嗦但真正常寫之后會發(fā)現(xiàn)它極其舒服。C語言里一個復雜函數(shù)的花括號嵌套會讓你數(shù)得眼花繚亂Python里縮進層次就是邏輯層次基本不會出現(xiàn)少寫一個右花括號導致一大片代碼邏輯錯亂這種經(jīng)典災難。2. if/elif/else條件分支的坑與正確姿勢2.1 真假值判斷Python的條件比你想象的寬泛絕大多數(shù)編程語言里if后面必須接一個布爾表達式true或false。Python不一樣它允許你在if后面放任意對象解釋器會沿著bool()這條隱式轉(zhuǎn)換路徑去判斷這個對象是真是假。這條規(guī)則極其重要因為新手在這個地方踩坑的概率非常高。Python中以下值在布爾上下文中全部被視為False常量False和None數(shù)值0、0.0、0j空字符串空列表[]、空元組()、空字典{}、空集合set()自定義對象中定義了__bool__()返回False或者定義了__len__()返回0除此之外的絕大多數(shù)對象都是True。這個設計最大的好處是你可以寫出非常自然的判斷代碼。比如判斷一個列表是否為空初學者可能會這樣寫if len(items) 0: print(有數(shù)據(jù))而Pythonic的寫法是if items: print(有數(shù)據(jù))同理判斷一個字符串是否為空# 不推薦 if name ! : print(名字不為空) # 推薦 if name: print(名字不為空)這兩者的邏輯等價但后者讀起來更像人話。如果items有東西、如果name非空這就是Python的truthiness機制帶來的表達紅利。不過要注意這有個前提是你清楚自己在判斷什么。如果你原本想判斷的是變量是None還是為空字符串那必須顯式寫if x is None和if not x這兩者有本質(zhì)區(qū)別——前者判斷身份后者判斷真假值?？兆址荈alseNone也是False但它們是兩個完全不同的值。另一個高頻踩坑點是和is的混淆。Python中比較的是值is比較的是內(nèi)存身份對象是否是同一個。對于小整數(shù)、短字符串這種被解釋器緩存的不可變對象5 is 5偶爾會返回True導致一些人誤以為is就是。一旦遇到大整數(shù)或者動態(tài)拼接的字符串is的結(jié)果就變成了False于是莫名其妙的bug就出現(xiàn)了。我的建議是判斷值用判斷是不是同一個對象比如對比None用is別混著來。2.2 elif不是else if的簡單縮寫Python里沒有其他語言那種else if關(guān)鍵字組合而是專門設計了elif。這一點本身沒什么坑但很多人對elif的理解停留在else if縮寫了這一層沒有真正理解它背后的執(zhí)行邏輯——短路匹配。看這個例子score 85 if score 90: grade A elif score 80: grade B elif score 70: grade C else: grade DPython解釋器會從上到下依次判斷每個條件。一旦某個條件為True執(zhí)行對應的代碼塊然后整個if-elif-else鏈直接結(jié)束后面的elif和else都不再判斷。這帶來一個非常實際的優(yōu)化思路條件順序會影響性能。如果一組條件互斥你應該把最容易命中的條件放在最前面。比如一個Web接口要校驗用戶身份先從緩存里取數(shù)據(jù)、再從數(shù)據(jù)庫取、最后才走外部接口那你應該把命中緩存這個概率最高的分支寫在最前面減少無謂的條件判斷。同時elif和多個獨立if有本質(zhì)區(qū)別。我見過有人寫出下面這種代碼if score 90: grade A if score 80: grade B # 注意如果score95這里會把grade又改成B兩個if之間沒有互斥關(guān)系都會依次執(zhí)行于是后面那個條件直接覆蓋了前面的結(jié)果。這是新手非常容易犯的邏輯錯誤——該用elif的時候用了if導致變量被多次賦值、結(jié)果被意外覆蓋。我建議在任何互斥分支場景下無條件選擇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)這種寫法我極其不建議在生產(chǎn)代碼里出現(xiàn)。嵌套三元表達式雖然語法上合法但讀起來要一層層扒開非常反人類。我的原則是三元表達式只用于簡單的兩者擇一一旦涉及三個及以上分支老老實實寫if-elif-else。用一個可以量化的標準來判斷——如果一行代碼超過80個字符或者需要括號包裹才能表達清楚就別用三元。3. for循環(huán)Python里最常用的流程控制結(jié)構(gòu)3.1 range的參數(shù)細節(jié)不只是三個數(shù)字range()是Python for循環(huán)里最常搭檔的內(nèi)置函數(shù)但它不像很多人想的那么簡單。完整寫法range(start, stop, step)生成的數(shù)字從start開始到stop結(jié)束前為止不包括stop本身間隔是step。這個左閉右開的設計讓很多新手困惑為什么range(5)生成的是0到4而不是0到5其實這是有數(shù)學上的考慮——它可以讓兩個相鄰range完美拼接而不重疊比如range(5)和range(5, 10)合起來正好是0到9中間沒有缺口也沒有重疊。幾個容易踩的細節(jié)range(5)等價于range(0, 5, 1)start默認0step默認1。如果只傳一個參數(shù)它代表stop傳兩個參數(shù)代表start和stop傳三個才是完整的。少傳參數(shù)時不要搞混位置。step可以為負數(shù)。range(5, 0, -1)生成[5, 4, 3, 2, 1]注意此時start必須大于stop否則循環(huán)體一次也不執(zhí)行。range()返回的不是列表而是一個range對象它是一個惰性序列。這意味著它不會占大量內(nèi)存——range(1000000000)并不會真的創(chuàng)建一個包含十億個數(shù)字的列表。但如果你直接打印range(5)看到的是range(0, 5)而不是[0, 1, 2, 3, 4]。在實際工作中最常見的循環(huán)場景是用range(len(...))配合下標訪問列表但這其實不太Pythonic。更好的方式是把迭代對象直接交給for循環(huán)# 不推薦 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的第二個參數(shù)start可以指定起始下標默認是0。很多業(yè)務場景比如從1開始編號都會用到這個參數(shù)。3.2 迭代對象解包for循環(huán)真正的威力Python for循環(huán)和其他語言最大的不同在于它不是一個數(shù)字計數(shù)器而是徹底的迭代協(xié)議。你不需要下標不需要手動遞增變量只要把任何可迭代對象放在in后面它就一個接一個地取出里面的元素。這個設計讓Python的循環(huán)表達能力遠超同類語言配合解包unpacking更是如虎添翼。同時遍歷兩個或多個列表用zip()names [張三, 李四, 王五] scores [88, 92, 76] for name, score in zip(names, scores): print(f{name}: {score})zip()的工作原理是并行地從每個可迭代對象中取出一個元素組合成元組。它的一個隱藏特性是以最短的迭代對象為準。如果你兩個列表長度不一致zip會默默截斷不報錯也不提示。這在某些場景下是我們想要的比如對齊前N個元素但在另一些場景下會造成數(shù)據(jù)靜默丟失。如果你需要嚴格校驗長度一致Python 3.10之后可以用zip(strictTrue)參數(shù)一旦長度不一致直接拋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官方文檔里特別提醒過遍歷字典時不要在循環(huán)體內(nèi)修改字典的大小增加或刪除鍵。因為字典遍歷依賴內(nèi)部的哈希表游標改動大小后行為是未定義的可能在Python 3.12里直接報RuntimeError: dictionary changed size during iteration。如果你確實需要邊遍歷邊刪數(shù)據(jù)先拷貝一份key列表for key in list(user_info.keys()):或者用字典推導式重建一個新字典。3.3 推導式把for循環(huán)壓成一行當你的循環(huán)體只是為了構(gòu)建一個列表、字典或集合時Python引入了一類極其簡潔的語法——推導式comprehension這是Python流程控制體系中我非常偏愛的一環(huán)。列表推導式的基本形式是[表達式 for 變量 in 可迭代對象 if 條件]# 傳統(tǒng)寫法 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]兩者的核心區(qū)別不僅在于代碼行數(shù)。推導式在CPython內(nèi)部有專門的優(yōu)化路徑執(zhí)行速度通常比等效的for循環(huán)append方式快20%-30%。在大規(guī)模數(shù)據(jù)處理場景下比如從幾萬條日志里提取特定字段這個性能差異是很明顯的。字典推導式和集合推導式同理# 字典推導式把列表變成索引字典 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}但我必須提醒一點——推導式不是萬能的。如果循環(huán)體里有多個語句、有副作用比如打印日志、修改其他變量、或者循環(huán)邏輯很復雜強行塞進推導式會讓代碼變得極其難讀。我見過一段嵌套了三層推導式的代碼看了整整一個下午才理清邏輯。這里的判斷標準是一行推導式能承載的邏輯復雜度是有限的超過兩個for或兩個if就應該寫成普通循環(huán)?？勺x性永遠優(yōu)先于簡潔性。4. while循環(huán)與循環(huán)控制四件套4.1 while和for的選型邏輯Python里的while循環(huán)語法很簡單while 條件:條件為真就反復執(zhí)行循環(huán)體直到條件變成假。但什么時候該用while、什么時候該用for很多人其實沒有想清楚。我的選型邏輯非常簡單如果你知道要迭代多少次且迭代對象是一組明確的數(shù)據(jù)用for如果你不知道要循環(huán)幾次、需要根據(jù)回路里的條件動態(tài)決定是否繼續(xù)用while。典型的使用while的場景從用戶輸入讀取數(shù)據(jù)直到輸入特定指令如quit才停止輪詢某個異步任務的狀態(tài)直到任務完成二分查找算法——每次循環(huán)把搜索區(qū)間減半直到區(qū)間為空游戲主循環(huán)——每一幀檢查退出條件下面是一個典型的讀輸入直到退出的寫法command while command ! quit: command input(請輸入指令輸入quit退出: ) # 處理指令寫while循環(huán)最需要警惕的問題就是死循環(huán)——條件永遠為真程序永遠不停。常見的原因條件里比較的變量沒有被更新或者更新邏輯寫在了continue之后導致永遠執(zhí)行不到。我在本地調(diào)試的時候一直強調(diào)一個習慣凡是寫while True:這種結(jié)構(gòu)先想清楚循環(huán)體內(nèi)哪一行代碼最終會讓break執(zhí)行到。如果找不到這一行那這代碼一跑就是一個死循環(huán)。4.2 break、continue、pass三個容易混淆的小角色break、continue、pass是流程控制里的三個小關(guān)鍵字作用完全不同混用的概率極高。break立即終止當前所在的整個循環(huán)不管循環(huán)條件是否還滿足。循環(huán)體后面的代碼不會執(zhí)行循環(huán)直接結(jié)束。continue跳過當前這一次迭代立即進入下一輪循環(huán)。注意在while循環(huán)中遇到continue會直接跳到條件判斷處在for循環(huán)中會跳到下一個元素的迭代。pass什么都不做就是個占位符。它本身不產(chǎn)生任何行為。網(wǎng)上有個經(jīng)典的坑新手想在循環(huán)里跳過空值并繼續(xù)寫了continue但放在錯誤的結(jié)構(gòu)里導致提前跳過了某段重要代碼。我們來看正確和錯誤的對比data [hello, , world, ] for item in data: if not item: continue # 跳過空字符串立即處理下一個元素 print(item.upper())這個沒問題。但如果有人把continue放在一個子循環(huán)內(nèi)部它跳過的只是內(nèi)層循環(huán)的本次迭代外層循環(huán)不受影響。很多人誤以為continue會跳過整個外層循環(huán)的下一次迭代實際并不是——它只作用于離它最近的那一層循環(huán)。這個細節(jié)在嵌套循環(huán)中非常容易引發(fā)邏輯bug。pass的典型用于場景是你還沒想好函數(shù)體里寫什么但如果不寫任何語句Python會因為函數(shù)體為空而報IndentationError。這時候可以用pass占位def send_retry_alert(retries): # TODO: 等運營把告警頻次規(guī)則定下來再實現(xiàn) pass4.3 被很多人低估的for-elsePython里有一個其他主流語言都沒有的特性——循環(huán)語句可以帶else分支我稱之為「循環(huán)的臨終遺言」。它的執(zhí)行規(guī)則是如果循環(huán)是正常結(jié)束的沒有被break中斷就執(zhí)行一次else分支如果循環(huán)是被break終止的else分支不執(zhí)行。這個特性在實戰(zhàn)中極其好用最常見的場景是在循環(huán)里搜索某個元素如果找到了就做一件事找不到做另一件事。傳統(tǒng)寫法是這樣的found False for user in users: if user.id target_id: found True break if not found: add_user(target_id)每次都要定義一個found標志位循環(huán)結(jié)束后再判斷一次。而用for-else可以寫得更自然for user in users: if user.id target_id: print(找到了) break else: add_user(target_id)當整個循環(huán)遍歷完都沒有執(zhí)行break時else里的代碼就執(zhí)行了相當于沒找到就補錄。很多C系語言的程序員看到這個會覺得不適應但掌握之后你會發(fā)現(xiàn)它避免了標志位變量邏輯清晰得多。不過這里有一個極其重要的陷阱如果循環(huán)體里連break都沒有else分支必定執(zhí)行。所以如果你寫了個普通循環(huán)沒帶break又誤加了else你可能會發(fā)現(xiàn)else里的代碼每次都會跑一遍。我就見過有人把else當成循環(huán)結(jié)束后不管怎樣都執(zhí)行來用了導致業(yè)務邏輯重復執(zhí)行。for-else的正確語義是循環(huán)未被中斷時執(zhí)行而不是循環(huán)結(jié)束后執(zhí)行。沒有break的循環(huán)配else除非你故意想用否則屬于邏輯錯誤。5. match-casePython 3.10帶來的流程控制新成員5.1 基本的模式匹配語法如果你用的是Python 3.10及以上版本那么流程控制家族里多了一位新成員——match-case語句。它看起來像其他語言里的switch-case但實質(zhì)上完全不同。match-case做的是結(jié)構(gòu)模式匹配不只是比較一個變量等于什么值還能根據(jù)數(shù)據(jù)的結(jié)構(gòu)、類型和具體字段來匹配。最簡單的用法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命中就執(zhí)行對應代碼塊并立即退出整個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。這種結(jié)構(gòu)性匹配讓代碼非常優(yōu)雅。5.2 什么時候值得用match-case我個人的判斷是match-case不是讓你把所有if-elif鏈都改掉而是在特定場景下有明顯優(yōu)勢判斷一個對象的類型和結(jié)構(gòu)。比如處理解析樹、處理JSON數(shù)據(jù)的多種形態(tài)、實現(xiàn)命令模式CLI指令分發(fā)。分支條件非常多。超過四五個elif的條件鏈用match-case會讓結(jié)構(gòu)更清晰。需要解包和命名的場景。case語句還支持用if加守衛(wèi)條件def classify_number(num): match num: case n if n 0: return 負數(shù) case 0: return 零 case n if n 10: return 一位數(shù) case n if n 100: return 兩位數(shù) case _: return 大數(shù)如果你在用Python 3.9或更早版本match-case會直接導致語法錯誤。老項目升級Python版本之前建議先用這個特性寫個小demo驗證環(huán)境沒問題再逐步把條件鏈改造成match-case。我見過有人把線上代碼切到match-case后直接SyntaxError整個服務起不來就是因為服務器上Python版本還是3.8。流程控制語法看著簡單但版本兼容性一點都不能馬虎。6. 真實項目踩坑記錄與排查復盤6.1 案例一循環(huán)中修改列表元素的詭異結(jié)果這個坑我印象很深。當時在做一個數(shù)據(jù)處理任務需要對列表里的每個元素做清洗如果元素違反規(guī)則就把它從列表中刪除。我的第一版代碼長這樣items [1, 2, 3, 4, 5, 6] for item in items: if item % 2 0: items.remove(item) print(items)我期望輸出的是所有偶數(shù)都被刪掉剩下[1, 3, 5]。但實際輸出是[1, 3, 5]不實際輸出是[1, 3, 5]之外的詭異結(jié)果——具體是[1, 3, 5]我再算一下。乖乖跑一遍遍歷索引0值為1不刪索引1值為2刪掉2列表變成[1, 3, 4, 5, 6]索引2此時是4原來的3被擠到了索引1的位置4是偶數(shù)刪掉列表變成[1, 3, 5, 6]索引3是6刪掉變成[1, 3, 5]。這個例子湊巧刪對了。但我把數(shù)據(jù)換一下就看出來了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已經(jīng)因為前面的刪除操作被移動到了索引6而循環(huán)早就走完了。這個問題的根源是在for循環(huán)遍歷列表的同時修改列表長度迭代器使用的下標和列表實際元素發(fā)生了錯位。排查思路復盤先打印每一步的列表內(nèi)容和當前遍歷到的值發(fā)現(xiàn)下標和值對不上。意識到for item in items本質(zhì)上是在內(nèi)部維護了一個整數(shù)下標每次迭代下標加1然后按下標取值。remove操作把后續(xù)元素往前挪導致有些元素被跳過。正確解法是改用列表推導式重建一個新列表items [item for item in items if item % 2 ! 0]或者如果你必須在原列表上操作先拷貝一份再迭代for item in list(items): if item % 2 0: items.remove(item)這個坑的教訓是凡是迭代集合時想同時修改集合刪除或增加元素必須拷貝一份或者改用推導式/新建列表的方式。這個規(guī)則適用于列表、字典、集合不僅限于for循環(huán)while循環(huán)里用下標操作也要格外小心。6.2 案例二短路邏輯救了你但你可能不知道有一次用Python寫一個配置校驗函數(shù)需要判斷一個配置項是否存在且取值合法。第一版代碼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的寫法是利用真值判斷比較# 需要先取出值避免重復調(diào)用get timeout config.get(timeout) if timeout and timeout 0: print(timeout合法)這里if timeout已經(jīng)利用了我們第2節(jié)講的真假值判斷——None是假0也是假。要注意的是如果你的合法值可能為0這種寫法會把0也排除掉這是另一個隱性問題。所以業(yè)務上真值可能為0時要改回is not None判斷。短路求值還帶來一個非常實用的技巧Python沒有其他語言的空值合并運算符但可以用or來模擬默認值效果username input_name or 游客當input_name為空字符串假值時整個表達式返回游客。這個寫法在配置讀取場景里用得非常廣泛但要注意如果input_name可能為0或False這類合法值不能這么寫。6.3 案例三for-else的else在我以為不會觸發(fā)時觸發(fā)了這是我親身經(jīng)歷的一次線上bug。當時有一段代碼需要在訂單列表里查找特定訂單找到就更新狀態(tài)沒找到就創(chuàng)建一個新訂單。我當時用了for-elsefor order in orders: if order.id new_order_id: update_order(order) break else: create_order(new_order_id)這段代碼有個隱患如果orders列表本身是空的for循環(huán)一次都不執(zhí)行但這不算被break中斷所以else分支照樣會執(zhí)行——于是創(chuàng)建了一個新訂單。這在業(yè)務上可能完全正確也可能不是你想要的行為。我那次遇到的實際情況是上游系統(tǒng)偶爾會傳一個空訂單列表過來結(jié)果系統(tǒng)每次都走create_order把本來應該判失敗的操作變成了創(chuàng)建新訂單數(shù)據(jù)里出現(xiàn)了大量重復的單子。排查鏈路是這樣的先看日志發(fā)現(xiàn)某個接口頻繁執(zhí)行創(chuàng)建訂單操作。翻代碼看到for-else邏輯第一反應覺得沒找到才創(chuàng)建邏輯沒問題。后來打印orders長度才發(fā)現(xiàn)列表為空時for循環(huán)體根本沒進過else直接執(zhí)行。這個坑的本質(zhì)是for-else中的else不關(guān)心循環(huán)體是否執(zhí)行過哪怕一次只關(guān)心循環(huán)是否被break終止。空列表遍歷也會觸發(fā)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)這段修復代碼還引入了一個重要的生成器函數(shù)any()它可以用來替代手寫for循環(huán)找元素的常見場景。類似地all()用來判斷是否所有元素滿足條件寫出來比for循環(huán)簡潔許多。這類隱藏的流程控制工具建議每個Python學習者在基礎語法之外專門過一遍。7. 幾個延續(xù)思考的進階方向如果你把前面這些內(nèi)容都消化了并且在自己的環(huán)境里把代碼都跑了一遍那么流程控制的基礎已經(jīng)打得很扎實了。接下來你想進階的話我建議按這個順序延伸迭代器與生成器。for循環(huán)背后其實是迭代協(xié)議理解__iter__和__next__能幫你明白為什么所有可迭代對象都能被for遍歷。生成器函數(shù)里的yield能寫出惰性求值的流程控制邏輯在處理超大文件、無限數(shù)據(jù)流時非常重要。異常處理作為流程控制。Python的try-except-else-finally結(jié)構(gòu)本質(zhì)上也是一種流程控制它決定了程序在出錯時走哪條路。尤其是try-except-else——try沒有異常時走else這個和for-else有異曲同工之妙很多新手同樣會搞混。上下文管理器。with語句里的__enter__和__exit__控制了資源申請和釋放的流程網(wǎng)絡連接、文件讀寫都用它這是Python資源管理的標準解法。并發(fā)場景下的循環(huán)控制。如果用asyncio寫協(xié)程async for可以異步遍歷數(shù)據(jù)流。這時候break、continue的語義雖然在但執(zhí)行時序要放在事件循環(huán)的框架里重新理解。Python的協(xié)程相關(guān)熱詞搜得越來越多這條線值得走。不過你有精力弄這塊之前先確保自己同步、同步異常處理都過關(guān)了再碰異步循環(huán)不然極其容易繞暈。我個人的體會是流程控制是任何編程語言的核心骨架學Python語法不把這一塊吃透后面的數(shù)據(jù)結(jié)構(gòu)、函數(shù)式編程、面向?qū)ο蠖紩u搖欲墜。但反過來只要這塊扎扎實實過了你去看任何Python項目源碼至少能順暢地讀下來——知道每一段代碼在什么條件下執(zhí)行、在哪個循環(huán)里跑。這個能力比記住幾個API重要得多。