在 Python 里待得久了你會(huì)發(fā)現(xiàn)真正決定代碼水平和寫代碼幸福感的東西往往不是那些花哨的框架和庫而是對(duì)語言本身這些基礎(chǔ)語法的理解深度。for和with這兩個(gè)關(guān)鍵字幾乎天天見但很多人對(duì)它們的認(rèn)知停留在“循環(huán)用 for打開文件用 with”的層面。這篇內(nèi)容我就以自己的實(shí)際經(jīng)驗(yàn)出發(fā)把這兩個(gè)語句掰開揉碎講清楚它們背后的機(jī)制、適用場(chǎng)景以及那些文檔里不會(huì)寫明白的坑。這是 Python 進(jìn)階之路系列里關(guān)于控制流的第二篇重點(diǎn)就是深入理解for語句和with語句。這篇文章適合誰看如果你已經(jīng)會(huì)用 Python 寫基本的循環(huán)和文件讀寫但總感覺自己在“背語法”而不是“用語言”遇到for...else、contextlib.closing這些東西會(huì)一愣那么這篇內(nèi)容就是為你準(zhǔn)備的。如果你是個(gè)純新手建議先把基礎(chǔ)語法過一遍再來看對(duì)for和with你會(huì)有更立體的理解。1. 全局視角為什么控制流里要單獨(dú)拿一章講 for 和 with大多數(shù)人學(xué)控制流的時(shí)候接觸的是if、for、while然后就是各種縮進(jìn)和冒號(hào)的規(guī)則。但真正進(jìn)入進(jìn)階階段后你會(huì)發(fā)現(xiàn)for和with在 Python 里的地位早就超過了“流程控制”本身它們已經(jīng)成為了語言與外部世界交互的兩種核心通道。1.1 for 不只是循環(huán)而是對(duì)“可迭代萬物”的消費(fèi)模式在 C 語言里for循環(huán)本質(zhì)上是基于計(jì)數(shù)器的初始化變量、判斷條件、更新變量。但 Python 的for完全不同它不需要計(jì)數(shù)器也沒有那種“循環(huán)變量自增”的概念。Python 的for是一種迭代器消費(fèi)模式——它拿過來任何一個(gè)對(duì)象先嘗試看看這個(gè)對(duì)象能不能被迭代如果可以就一次次從中取出元素處理直到取完。這個(gè)設(shè)計(jì)讓for的適用范圍變得極其寬廣你能for一個(gè)列表也能for一個(gè)字符串甚至能for一個(gè)文件對(duì)象、一個(gè)數(shù)據(jù)庫游標(biāo)、一個(gè)網(wǎng)絡(luò)請(qǐng)求的響應(yīng)流。只要這個(gè)對(duì)象實(shí)現(xiàn)了迭代協(xié)議都可以用同一套語法去消費(fèi)。這種統(tǒng)一性是 Python 在數(shù)據(jù)處理領(lǐng)域如此高效的重要原因之一。1.2 with 盯住的是“生命周期”,解決的是資源釋放問題with的定位和for就不一樣了它誕生得晚一些Python 2.5 開始引入它盯住的是資源生命周期。你可能遇到過這種場(chǎng)景打開一個(gè)文件操作完忘記關(guān)閉程序繼續(xù)運(yùn)行文件一直被占用著。在 Windows 上這種問題會(huì)直接導(dǎo)致文件刪除失敗或者被鎖定。with就是在這樣的痛點(diǎn)下被廣泛使用的。它的語法背后是一個(gè)上下文管理協(xié)議。通俗地講就像你進(jìn)入一個(gè)會(huì)議室開會(huì)進(jìn)門需要開門出門需要鎖門無論會(huì)議開的過程如何正常開完、開一半斷電了、還是出了事故鎖門這個(gè)動(dòng)作都必須要執(zhí)行。with語句保證的就是“進(jìn)得了門就一定鎖得了門”這個(gè)鎖門對(duì)應(yīng)的就是資源的清理和釋放。所以for是對(duì)數(shù)據(jù)的迭代入口with是外部資源的保管閘門。別看都是關(guān)鍵字底層哲學(xué)完全不是一回事。這一章把它們放在一起正因?yàn)檫M(jìn)階開發(fā)者在處理真實(shí)任務(wù)時(shí)往往要同時(shí)面對(duì)“迭代中的資源需要手動(dòng)管理”和“資源管理器本身需要被迭代”這兩種情況兩者經(jīng)?；ハ嗉m纏。2. 深入理解 for 語句迭代協(xié)議與執(zhí)行細(xì)節(jié)現(xiàn)在開始正題。很多人以為自己會(huì)用for其實(shí)只知道了它的九牛一毛。我們先從迭代協(xié)議講起這是我個(gè)人覺得所有 Python 學(xué)習(xí)者都該盡早搞明白的一塊地基。2.1 可迭代對(duì)象與迭代器兩個(gè)被混淆的概念先丟出兩個(gè)概念可迭代對(duì)象和迭代器。這兩者經(jīng)常被混用但在 Python 里它們是不同的東西?？傻鷮?duì)象Iterable實(shí)現(xiàn)了__iter__()方法的對(duì)象或者實(shí)現(xiàn)了__getitem__()且下標(biāo)從 0 開始索引的對(duì)象。簡(jiǎn)單說只要是能被for直接遍歷的對(duì)象都是可迭代對(duì)象。列表、元組、字典、字符串、集合都是可迭代對(duì)象。迭代器Iterator同時(shí)實(shí)現(xiàn)了__iter__()和__next__()方法的對(duì)象。每次調(diào)用__next__()它會(huì)返回下一個(gè)元素如果沒元素了會(huì)拋出StopIteration異常。迭代器是一個(gè)“一次性用品”遍歷完就沒有了。所以每次當(dāng)你寫for item in my_list: print(item)背后發(fā)生的事情實(shí)際上是 Python 調(diào)用了iter(my_list)拿到了一個(gè)迭代器然后不停地調(diào)用迭代器的__next__()方法直到StopIteration被拋出為止。這個(gè)流程是隱式的for幫你把異常處理掉了讓你看不到這些細(xì)節(jié)但理解了這個(gè)流程你才能解釋清楚很多詭異的問題。舉個(gè)例子很多人不知道為什么一個(gè)生成器只能遍歷一次numbers (x for x in range(5)) print(sum(numbers)) # 10 print(sum(numbers)) # 0因?yàn)樯善鞅旧砭褪且粋€(gè)迭代器第一次sum就把它的元素消費(fèi)光了第二次自然為 0。但如果是列表就不會(huì)有這種問題因?yàn)榱斜硎强傻鷮?duì)象每次for都會(huì)重新調(diào)用iter()創(chuàng)建一個(gè)新的迭代器。2.2 for 循環(huán)執(zhí)行流程的拆解for語句的完整執(zhí)行流程如果用手寫代碼展開的話分段去看會(huì)更清晰# 下面的 for 循環(huán) for item in iterable: do_something(item) # 其實(shí)等價(jià)于下面這段代碼的簡(jiǎn)化封裝 _iter iter(iterable) while True: try: item next(_iter) except StopIteration: break else: do_something(item)很多新手看到這里會(huì)恍然大悟原來for底層還是一個(gè)while套try-except。這個(gè)展開式的意義在于它讓我明白了三件事第一for本身沒有循環(huán)計(jì)數(shù)器迭代的推進(jìn)完全靠迭代器的__next__這意味著無法在語法層面控制“步長(zhǎng)”。所以很多從其他語言轉(zhuǎn)過來的同學(xué)想實(shí)現(xiàn)“i 從 0 到 10 每次加 2”的效果一開始都會(huì)到處找 Python 的 for 步長(zhǎng)語法其實(shí)應(yīng)該用while或者range去模擬。第二因?yàn)楫惓Ｊ莊or內(nèi)部處理的如果do_something(item)這個(gè)循環(huán)體內(nèi)部拋出了異常異常會(huì)直接中斷整個(gè)循環(huán)并向外傳播而不是被StopIteration邏輯捕獲。這個(gè)看起來理所當(dāng)然的行為在實(shí)際排查問題時(shí)非常重要——你永遠(yuǎn)不會(huì)因?yàn)樵趖ry里寫了StopIteration就莫名其妙吞掉循環(huán)體里的業(yè)務(wù)異常。第三迭代是“惰性”的一次只取一個(gè)。這看起來和密集計(jì)算的for i in range(...)沒什么區(qū)別但如果你面對(duì)的是數(shù)據(jù)流、日志文件、網(wǎng)絡(luò)響應(yīng)惰性迭代能讓你實(shí)現(xiàn)真正意義上的流式處理。我的一個(gè)實(shí)踐經(jīng)驗(yàn)是用for處理一個(gè) 10GB 的日志文件時(shí)完全不會(huì)爆內(nèi)存雖然文件讀起來確實(shí)是逐行進(jìn)行的。2.3 range、enumerate、zip 的進(jìn)階用法與坑這幾個(gè)內(nèi)置函數(shù)在for循環(huán)里出現(xiàn)頻率極高但用法上確實(shí)有一些值得挖掘的細(xì)節(jié)。range本身是一個(gè)惰性序列對(duì)象并不一次性生成所有數(shù)字。range(10**9)瞬間完成但內(nèi)存占用極小因?yàn)樗淮鎯?chǔ)了起始值、終止值和步長(zhǎng)用的時(shí)候才實(shí)時(shí)計(jì)算當(dāng)前值。這是 Python 3 相比 Python 2 的一個(gè)重要性能改進(jìn)。實(shí)際寫代碼時(shí)要注意的是range的結(jié)束邊界是左閉右開range(1, 4)生成 1、2、3 而不是 4。這個(gè)左右邊界問題我見過太多人栽在上面送分題變成送命題。enumerate的價(jià)值在于同時(shí)獲取索引和值。有個(gè)容易被忽略的參數(shù)是startfor idx, line in enumerate(file_obj, start1): print(f第 {idx} 行: {line.strip()})文件從第 1 行開始計(jì)數(shù)再也不用寫idx 1了。這個(gè)start參數(shù)在日志處理、表格導(dǎo)出這些對(duì)行號(hào)敏感的場(chǎng)合特別實(shí)用。zip用于并行迭代多個(gè)序列。它的一個(gè)坑是如果兩個(gè)序列長(zhǎng)度不一致zip默認(rèn)以短的為主多余的元素會(huì)被靜默丟棄。如果你期待的是嚴(yán)格對(duì)齊要么用zip_longest在itertools里它會(huì)用填充值補(bǔ)齊短序列。我遇到過一個(gè)生產(chǎn)事故就是因?yàn)閦ip靜默截?cái)嗔藘蓚€(gè)不同長(zhǎng)度的列表導(dǎo)致數(shù)據(jù)錯(cuò)位但沒報(bào)錯(cuò)。排查了很久。在你的代碼里如果兩個(gè)序列長(zhǎng)度由不同來源產(chǎn)生建議先顯式斷言長(zhǎng)度相等或者直接選用zip_longest并用哨兵值檢查。2.4 列表推導(dǎo)式與生成器表達(dá)式for 的另一種存在形式列表推導(dǎo)式可以看作是for的一個(gè)“表達(dá)式版本”squares [x ** 2 for x in range(20) if x % 2 0]這段代碼等價(jià)于squares [] for x in range(20): if x % 2 0: squares.append(x ** 2)但兩者有一個(gè)關(guān)鍵區(qū)別列表推導(dǎo)式是表達(dá)式它的執(zhí)行速度通常更快因?yàn)閮?nèi)部的迭代與追加操作是在 C 層面高度優(yōu)化的Python 字節(jié)碼層面省去了大量的append方法查找。我在測(cè)試一個(gè)基于列表過濾構(gòu)建的任務(wù)列表時(shí)列表推導(dǎo)式比顯式for if append快 20% 到 30%。數(shù)據(jù)量越大差距越明顯。不過建議你注意列表推導(dǎo)式雖好也不要濫用。超過兩三層嵌套、或者里面有復(fù)雜的異常處理邏輯時(shí)老老實(shí)實(shí)寫for循環(huán)可讀性遠(yuǎn)比那一點(diǎn)性能節(jié)省重要得多?？勺x性永遠(yuǎn)是你和未來同事之間最重要的契約。生成器表達(dá)式就是把方括號(hào)換成圓括號(hào)total sum(x * x for x in range(100))它在內(nèi)存占用上有巨大的優(yōu)勢(shì)尤其是面對(duì)海量數(shù)據(jù)時(shí)。我自己處理過千萬級(jí)的數(shù)據(jù)匯總用列表推導(dǎo)式直接內(nèi)存爆炸換成生成器表達(dá)式后內(nèi)存穩(wěn)定在幾十兆。這個(gè)經(jīng)驗(yàn)在數(shù)據(jù)處理類項(xiàng)目里幾乎每天用到。2.5 for...else很多人學(xué)不會(huì)的冷門語法Python 的for可以帶一個(gè)else子句它表示循環(huán)正常結(jié)束沒被break打斷時(shí)會(huì)執(zhí)行else中的代碼。這個(gè)語法我第一次遇到時(shí)也覺得奇怪但它在搜索場(chǎng)景中真的很好用。舉個(gè)例子判斷一個(gè)數(shù)是否為質(zhì)數(shù)import math def is_prime(n: int) - bool: if n 2: return False for i in range(2, int(math.sqrt(n)) 1): if n % i 0: print(f{n} 可以被 {i} 整除) break else: return True return Falsefor...else解決了一個(gè)之前只能靠旗標(biāo)變量flag才能解決的問題。如果你不用它就得寫一個(gè)found False然后找到時(shí)設(shè)置found True循環(huán)結(jié)束后再檢查found。這個(gè)寫法算法層面當(dāng)然沒問題但直覺上不是那么直接且更容易在復(fù)雜業(yè)務(wù)里漏掉分支。不過我在實(shí)際業(yè)務(wù)代碼里給團(tuán)隊(duì)定的一個(gè)規(guī)范是for...else可以少量使用但必須寫注釋說明邏輯意圖。因?yàn)榇_實(shí)有相當(dāng)多開發(fā)者不知道這個(gè)語法第一次看到時(shí)會(huì)困惑“這個(gè) else 到底是和哪個(gè) if 配對(duì)的”。保持協(xié)作效率注釋不可少。2.6 for 循環(huán)在常見可變對(duì)象上的注意點(diǎn)這條算是我踩過的坑值得專門拿出來講不要在迭代列表時(shí)隨意刪除元素。比如my_list [1, 2, 3, 4, 5, 6] for item in my_list: if item % 2 0: my_list.remove(item)這段代碼的本意是剔除所有偶數(shù)但運(yùn)行時(shí)會(huì)出現(xiàn)詭異的結(jié)果你最后得到的列表是[1, 3, 5]還是[1, 3, 6]答案是后者或者在不同的 Python 版本下還有其他離奇表現(xiàn)。原因在于remove操作改變了列表的底層結(jié)構(gòu)而迭代器內(nèi)部維護(hù)的下標(biāo)并不知道這個(gè)變化導(dǎo)致跳過了某些元素。正確的做法是創(chuàng)建一個(gè)副本去迭代for item in my_list[:]: if item % 2 0: my_list.remove(item)或者用更 Pythonic 的列表推導(dǎo)式my_list [x for x in my_list if x % 2 ! 0]第二個(gè)做法更安全、更高效。同樣的問題也存在于字典在for循環(huán)里直接修改字典鍵值、增加鍵值都非常危險(xiǎn)會(huì)拋出RuntimeError: dictionary changed size during iteration或者更隱蔽地導(dǎo)致邏輯錯(cuò)亂。需要遍歷字典并修改時(shí)先迭代list(dict.keys())或者干脆構(gòu)建一個(gè)新字典。3. 可迭代對(duì)象和迭代器的工程實(shí)踐從手寫類到生成器光理解概念還不夠。作為一個(gè)進(jìn)階者你需要會(huì)自己構(gòu)造可迭代對(duì)象能掌控它的迭代行為。3.1 手寫一個(gè)迭代器類假設(shè)你需要一個(gè)迭代器每調(diào)用一次就返回下一個(gè)斐波那契數(shù)注意它是“無界”的你不能預(yù)先算好放列表里。這種情況下就需要自己寫迭代器。一個(gè)最小實(shí)現(xiàn)如下class FibonacciIterator: 斐波那契數(shù)列迭代器支持指定最大項(xiàng)數(shù) def __init__(self, max_count: int): self.max_count max_count self.count 0 self.a, self.b 0, 1 def __iter__(self): return self def __next__(self): if self.count self.max_count: raise StopIteration result self.a self.a, self.b self.b, self.a self.b self.count 1 return result for num in FibonacciIterator(10): print(num)這里面有個(gè)容易被忽略的細(xì)節(jié)__iter__返回了self也就是迭代器本身。它的意思是“我這個(gè)對(duì)象迭代自己”。這種設(shè)計(jì)在很多標(biāo)準(zhǔn)庫類中很常見。對(duì)一個(gè)迭代器來說__iter__返回自身是合理且常規(guī)的。手寫迭代器的意義在于當(dāng)你的迭代邏輯不是簡(jiǎn)單數(shù)組遍歷而是涉及狀態(tài)計(jì)算、外部數(shù)據(jù)流讀取、或者需要保存遍歷過程中的一些中間狀態(tài)時(shí)類會(huì)讓你更容易組織代碼。我在開發(fā)一個(gè)分頁拉取外部文件列表的小工具時(shí)就是這樣寫了一個(gè)迭代器類把分頁參數(shù)、緩存、頁碼狀態(tài)都封裝起來對(duì)外就是一個(gè)干凈的for ... in接口。3.2 生成器迭代器的平民化寫法如果你覺得寫一個(gè)完整的迭代器類太啰嗦生成器就是降維方案。帶yield的函數(shù)就是生成器函數(shù)。它的特點(diǎn)很反直覺函數(shù)體里的代碼并不會(huì)在調(diào)用時(shí)立即執(zhí)行而是在迭代時(shí)才按需執(zhí)行。def fibonacci_generator(max_count: int): a, b 0, 1 count 0 while count max_count: yield a a, b b, a b count 1 for num in fibonacci_generator(10): print(num)yield關(guān)鍵字把函數(shù)變成了“可暫停的”。每次迭代到y(tǒng)ield函數(shù)就暫停在那個(gè)位置保存所有局部變量狀態(tài)把值傳給外部下一次迭代時(shí)從暫停的位置繼續(xù)執(zhí)行。這個(gè)特性不知道幫多少人把復(fù)雜的狀態(tài)機(jī)邏輯簡(jiǎn)化成了順序代碼。這里有個(gè)工程上的建議盡量用生成器函數(shù)代替返回列表的函數(shù)尤其是當(dāng)函數(shù)內(nèi)部會(huì)構(gòu)造一個(gè)很大的中間列表時(shí)。比如一個(gè)從數(shù)據(jù)庫取出百萬行記錄然后返回列表的函數(shù)改成生成器后變成一條一條地取、一條一條地交給你處理內(nèi)存占用是整個(gè)系統(tǒng)是否可用的關(guān)鍵差異。不過別忘了一件事生成器是有狀態(tài)的、單次使用的。函數(shù)里如果同時(shí)需要訪問生成器的多個(gè)方面或者需要隨機(jī)訪問數(shù)據(jù)生成器并不是好選擇老老實(shí)實(shí)用列表或其它序列容器。3.3 iter() 函數(shù)的兩個(gè)隱藏用法iter()函數(shù)絕大多數(shù)人只用到它的基本形態(tài)iter(iterable)。但它有一個(gè)少見但威力強(qiáng)大的用法用兩個(gè)參數(shù)調(diào)用iter(callable, sentinel)。它會(huì)反復(fù)調(diào)用callable直到返回值等于sentinel時(shí)停止。比如從標(biāo)準(zhǔn)輸入讀取行直到遇到空行l(wèi)ines [] for line in iter(input, ): lines.append(line)不再需要while Truebreak的組合一行for搞定。讀文件直到某行結(jié)束符、讀取傳感器數(shù)據(jù)直到一個(gè)特定的終止值都是這個(gè)用法的典型應(yīng)用。雖然業(yè)務(wù)場(chǎng)景不算高頻但用上后代碼會(huì)顯得非常干凈。4. 深入理解 with 語句上下文管理器與資源控制現(xiàn)在進(jìn)入with。它大概是 Python 中最被低估的語法之一。看著簡(jiǎn)單實(shí)際上設(shè)計(jì)得非常精妙。4.1 上下文管理協(xié)議enter與exit一個(gè)對(duì)象如果想支持with語句它必須實(shí)現(xiàn)兩個(gè)魔法方法__enter__(self)當(dāng)進(jìn)入with代碼塊時(shí)被調(diào)用。它的返回值會(huì)賦給as后面的變量。__exit__(self, exc_type, exc_val, exc_tb)當(dāng)代碼塊結(jié)束不管正常結(jié)束還是異常結(jié)束時(shí)被調(diào)用。它接收異常相關(guān)的三個(gè)參數(shù)如果代碼塊中沒有發(fā)生異常這三個(gè)參數(shù)都是None。用一段展開式來看with open(data.txt, r) as f: content f.read()其實(shí)等價(jià)于_manager open(data.txt, r) try: __enter__result _manager.__enter__() content __enter__result.read() except Exception: _manager.__exit__(*sys.exc_info()) raise else: _manager.__exit__(None, None, None)注意__exit__的調(diào)用時(shí)機(jī)有兩種路徑異常發(fā)生時(shí)調(diào)用一次正常結(jié)束時(shí)也調(diào)用一次。如果你在__exit__中返回True異常會(huì)被吞掉不再向外拋出返回None或False異常會(huì)繼續(xù)傳播。這個(gè)“吞掉異?！钡哪芰κ窃O(shè)計(jì)容錯(cuò)上下文管理器時(shí)可以動(dòng)用的一個(gè)底牌。4.2 文件操作with 最經(jīng)典的應(yīng)用文件操作是with最經(jīng)典的場(chǎng)景。老實(shí)說不寫with的人寫文件代碼極容易把文件句柄漏掉。而with保證文件一定被關(guān)閉無論代碼塊內(nèi)發(fā)生了什么。在處理大文件、批量文件、日志輪轉(zhuǎn)這類場(chǎng)景反復(fù)開合文件時(shí)這個(gè)保證非常關(guān)鍵。要注意的是open()的__enter__返回的是文件對(duì)象本身所以你直接用as f拿到它繼續(xù)調(diào)用.read()、.write()沒問題。文件關(guān)閉后如果還試圖訪問f會(huì)得到一個(gè)ValueError: I/O operation on closed file。這個(gè)報(bào)錯(cuò)相信踩過的人都記得。4.3 鎖與線程同步在并發(fā)編程里with是鎖操作的標(biāo)準(zhǔn)寫法import threading lock threading.Lock() def safe_increment(counter): with lock: counter[value] 1 return counter[value]如果你不用with就要寫lock.acquire()和lock.release()而且必須確保中間的代碼不會(huì)提前return或拋異常否則release就漏了。死鎖就是這么來的。with用上下文管理器把a(bǔ)cquire和release封裝成自動(dòng)成對(duì)的行為可以從結(jié)構(gòu)上杜絕這類資源泄漏。還有遞歸鎖RLock同樣支持with。我處理過一個(gè)并發(fā)庫存扣減的系統(tǒng)核心邏輯就是用with包住資源操作整體多線程跑幾個(gè)月都沒出過鎖相關(guān)的問題。with在這里不只是語法糖是并發(fā)安全的基石。4.4 數(shù)據(jù)庫事務(wù)處理連接與光標(biāo)的上下文場(chǎng)景數(shù)據(jù)庫連接和游標(biāo)也是with的黃金場(chǎng)景。許多數(shù)據(jù)庫驅(qū)動(dòng)比如sqlite3的連接、psycopg2的游標(biāo)都實(shí)現(xiàn)了上下文管理器。但要注意sqlite3的連接對(duì)象作為上下文管理器時(shí)它管理的不是連接的關(guān)閉而是事務(wù)的提交或回滾import sqlite3 conn sqlite3.connect(app.db) try: with conn: conn.execute(INSERT INTO users(name) VALUES (?), (Alice,)) conn.execute(INSERT INTO users(name) VALUES (?), (Bob,)) except sqlite3.Error: pass當(dāng)with塊正常結(jié)束時(shí)事務(wù)提交如果塊內(nèi)發(fā)生異常事務(wù)回滾。這個(gè)行為比手動(dòng)調(diào)用commit()/rollback()更可靠尤其適合“一批操作要么全部成功要么全部回滾”的原子性要求。但連接本身的關(guān)閉還是需要手動(dòng)close()或另一個(gè)上下文處理。如果你用的是 ORM 的 session通常 session 本身也會(huì)提供類似的上下文接口?？傊诵乃悸肥怯猛昴茏詣?dòng)回收的東西都納入with來管理。4.5 實(shí)現(xiàn)你自己的上下文管理器你可能會(huì)想什么時(shí)候需要自己寫上下文管理器我的經(jīng)驗(yàn)是當(dāng)你有一段代碼需要“前置準(zhǔn)備”和“后置清理”時(shí)把它包成一個(gè)上下文管理器能大幅提高復(fù)用性。最簡(jiǎn)單的實(shí)現(xiàn)方式是使用contextlib.contextmanager裝飾器from contextlib import contextmanager contextmanager def timer(name: str): import time start time.perf_counter() try: yield finally: elapsed time.perf_counter() - start print(f[{name}] 耗時(shí): {elapsed:.4f} 秒) with timer(數(shù)據(jù)加載): data load_large_data()yield之前的部分是__enter__yield之后的部分是__exit__。finally塊里的內(nèi)容保證無論異常與否都會(huì)執(zhí)行。這個(gè)模式被我常年用于性能分析、臨時(shí)環(huán)境變量設(shè)置、日志上下文標(biāo)注等場(chǎng)景。如果你想用類的方式實(shí)現(xiàn)比如需要保存比較復(fù)雜的狀態(tài)就實(shí)現(xiàn)__enter__和__exit__兩個(gè)方法。我寫過的一個(gè)典型例子是“臨時(shí)切換當(dāng)前工作目錄并自動(dòng)恢復(fù)”import os from contextlib import contextmanager contextmanager def working_directory(path): current os.getcwd() try: os.chdir(path) yield finally: os.chdir(current)4.6 contextlib 模塊的工程價(jià)值標(biāo)準(zhǔn)庫的contextlib一個(gè)寶藏工具集掌握了它你的資源管理能力會(huì)再上一個(gè)臺(tái)階。contextlib.closing(obj)用于那些沒有實(shí)現(xiàn)上下文協(xié)議但有關(guān)閉方法的對(duì)象。比如舊的urllib.request.urlopen返回的對(duì)象或者某些第三方庫的客戶端。把它包進(jìn)closing就能用with保證close()被調(diào)用。from contextlib import closing with closing(some_legacy_client.connect()) as client: client.query(...)contextlib.suppress(*exceptions)優(yōu)雅地忽略指定異常避免寫空的except。from contextlib import suppress import os with suppress(FileNotFoundError): os.remove(tmp.txt)比try...except FileNotFoundError: pass更直觀。contextlib.ExitStack動(dòng)態(tài)管理多個(gè)上下文管理器或者不確定自己要進(jìn)入多少個(gè)上下文的時(shí)候特別有用。我在寫一個(gè)需要同時(shí)打開多個(gè)資源的多步驟任務(wù)時(shí)喜歡用ExitStack統(tǒng)一登記要清理的對(duì)象最后統(tǒng)一退出from contextlib import ExitStack with ExitStack() as stack: f1 stack.enter_context(open(file1.txt, r)) f2 stack.enter_context(open(file2.txt, r)) db_conn stack.enter_context(get_connection()) # ... 整個(gè)邏輯結(jié)束f1、f2、db_conn 會(huì)自動(dòng)按登記順序逆序清理這個(gè)模式在插件式架構(gòu)、動(dòng)態(tài)組合任務(wù)中尤其好用。4.7 with 與異常交互的微妙之處__exit__的第一個(gè)參數(shù)是異常類型這給了你很大的操作空間。你可以根據(jù)“發(fā)生了異常才需要特殊處理”來決定退出邏輯。我在做寫文件操作時(shí)經(jīng)常會(huì)在__exit__里判斷如果代碼塊拋了異常就刪除已經(jīng)寫了一半的臨時(shí)文件防止留下臟數(shù)據(jù)。這個(gè)用普通try...finally也能實(shí)現(xiàn)但放進(jìn)上下文管理器后這種清理邏輯就能被復(fù)用。還有一個(gè)容易產(chǎn)生困惑的點(diǎn)__exit__返回True會(huì)吞掉異常。如果你在上下文管理器里故意返回了True外層調(diào)用者將看不到異常這有時(shí)會(huì)導(dǎo)致 bug 悄悄發(fā)生。除非你有意這么做比如把某種異常當(dāng)作正常邏輯否則不要隨便返回True。5. for 和 with 協(xié)同使用的實(shí)操經(jīng)驗(yàn)講完各自的原理這一節(jié)把兩者放在一個(gè)具體的任務(wù)場(chǎng)景里看看它們?cè)趺磁浜?。這是我認(rèn)為進(jìn)階學(xué)習(xí)者最需要的一種視角實(shí)際開發(fā)中我們幾乎不會(huì)只用for也不會(huì)只用with更多時(shí)候是它們的嵌套配合。5.1 用 with 管理文件用 for 逐行消費(fèi)最典型的場(chǎng)景就是讀取一個(gè)超大文本文件日志、CSV、中間數(shù)據(jù)逐行處理from pathlib import Path with Path(huge_access.log).open(r, encodingutf-8, errorsignore) as f: for line in f: process_line(line) # for 結(jié)束后文件已在 with 退出時(shí)自動(dòng)關(guān)閉這里有個(gè) Python 文件迭代的重要特點(diǎn)文件對(duì)象本身是迭代器for line in f會(huì)按行讀取且內(nèi)部有緩沖優(yōu)化效率很高。很多人一看到大文件就下意識(shí).readlines()這會(huì)一次性加載整個(gè)文件到內(nèi)存內(nèi)存幾 GB 的文件直接讓服務(wù)崩潰。with在這里的作用有兩個(gè)一是保證文件關(guān)閉二是把文件的“生命周期”限定在with塊內(nèi)塊內(nèi)代碼結(jié)束文件資源的使命就結(jié)束了。所有拉取日志分析的腳本我都建議遵循這個(gè)模式。5.2 嵌套多個(gè) with 的最佳實(shí)踐需要同時(shí)打開兩個(gè)文件做合并操作時(shí)很多人會(huì)寫with open(a.txt) as f1: with open(b.txt) as f2: pass這種嵌套沒問題但在 Python 3.10 中可以避免二級(jí)縮進(jìn)帶來的視覺混亂with open(a.txt) as f1, open(b.txt) as f2: for line1, line2 in zip(f1, f2): passzip在這里搭配with的多上下文管理簡(jiǎn)直順手。但要留意前面提過的zip靜默截?cái)鄦栴}如果兩個(gè)文件行數(shù)差距較大建議用itertools.zip_longest顯式處理。5.3 在 with 塊內(nèi)部生成數(shù)據(jù)并返回迭代器這里有一個(gè)很多人會(huì)踩的坑在with塊內(nèi)讀取文件到一個(gè)生成器然后with塊結(jié)束后再去迭代這個(gè)生成器。比如def read_lines(path): with open(path, r) as f: return (line.strip() for line in f) lines read_lines(test.txt) # 此時(shí)文件已經(jīng)關(guān)閉了 for line in lines: print(line) # ValueError!生成器表達(dá)式是惰性的它等到迭代時(shí)才會(huì)真正執(zhí)行讀取。問題是with在函數(shù)返回時(shí)就退出了文件已經(jīng)被關(guān)閉了等你后面迭代時(shí)再去讀文件內(nèi)容就會(huì)報(bào)錯(cuò)。解決方法是把with移到使用生成器的地方的外層或者老老實(shí)實(shí)在with塊內(nèi)完成數(shù)據(jù)的消費(fèi)。這個(gè)坑在真實(shí)代碼里隱蔽性極強(qiáng)因?yàn)閳?bào)錯(cuò)并不是一定發(fā)生的如果文件內(nèi)容已經(jīng)被操作系統(tǒng)緩存你可能僥幸讀到內(nèi)容如果文件被其他程序改動(dòng)了或者緩存過期則可能得到奇怪的數(shù)據(jù)。不要靠運(yùn)氣寫代碼。5.4 爬蟲或數(shù)據(jù)抓取場(chǎng)景中的 for with在處理網(wǎng)絡(luò)請(qǐng)求時(shí)經(jīng)常需要循環(huán)請(qǐng)求多個(gè) URL每個(gè)請(qǐng)求都要確保連接被正確關(guān)閉。用requests配合with是一個(gè)非常干凈的寫法import requests urls [...] for url in urls: with requests.get(url, streamTrue, timeout10) as resp: for chunk in resp.iter_content(chunk_size8192): process_chunk(chunk)這個(gè)寫法既保證了每次響應(yīng)對(duì)象的資源釋放又實(shí)現(xiàn)了流式處理不會(huì)一次性把整個(gè)響應(yīng)體加載進(jìn)內(nèi)存。如果你面對(duì)的是大批量的外部接口調(diào)用這個(gè)組合能讓你既不崩內(nèi)存也不漏資源。多年以來我處理各類數(shù)據(jù)采集任務(wù)用的就是這套。6. 常見問題與排查思路實(shí)錄把自己在實(shí)踐和做技術(shù)支持時(shí)所見到的高頻問題整理一下以問答形式講清楚這樣比較方便查閱。6.1 循環(huán)中修改列表導(dǎo)致元素跳過或意外錯(cuò)誤現(xiàn)象迭代列表時(shí)刪除元素結(jié)果有些該處理的數(shù)據(jù)被跳過了。原因列表迭代器基于下標(biāo)推進(jìn)刪除元素會(huì)導(dǎo)致后續(xù)元素前移迭代器并不知道這個(gè)變化。建議迭代副本my_list[:]或通過列表推導(dǎo)式創(chuàng)建新列表。需要原地修改數(shù)組時(shí)考慮從后往前遍歷因?yàn)閯h除尾部元素不會(huì)影響前面未迭代的位置。6.2for...else沒有被執(zhí)行現(xiàn)象else分支的內(nèi)容完全沒有輸出。原因最常見的原因是循環(huán)體內(nèi)提前break了一旦breakelse就不執(zhí)行。另一個(gè)原因是else被錯(cuò)誤地并到了某個(gè)if語句上而不是for上。Python 中for...else是一體的中間不能插入別的語句。建議先確認(rèn)自己的break條件是不是真的“找到了結(jié)果”。另外在 IDE 里用縮進(jìn)和括號(hào)輔助區(qū)分else對(duì)齊for。6.3 with 打開文件后報(bào)“closed file”現(xiàn)象with塊外還去訪問文件對(duì)象。原因生命周期明確限定在塊內(nèi)。文件已經(jīng)關(guān)閉了不要再嘗試引用它。建議把需要在文件打開期間處理的數(shù)據(jù)先提取到普通變量中等with結(jié)束后繼續(xù)使用這些變量。6.4 with 塊內(nèi)拋出異常但不想中斷程序現(xiàn)象with塊內(nèi)出現(xiàn)某個(gè)可預(yù)期的異常外層程序崩了。原因with默認(rèn)不會(huì)吞掉異常異常照常傳播。建議用contextlib.suppress顯式忽略確定無害的異常或者自己實(shí)現(xiàn)__exit__并針對(duì)特定異常返回True但務(wù)必想清楚是否真的該吞。6.5 嵌套上下文管理器太多導(dǎo)致縮進(jìn)地獄現(xiàn)象多重with嵌套代碼層層縮進(jìn)。建議用逗號(hào)合寫多個(gè)上下文管理器如with a() as a1, b() as b1復(fù)雜場(chǎng)景用ExitStack。這不僅能減少縮進(jìn)還能讓清理順序更清晰。6.6 迭代器耗盡后無法重置現(xiàn)象對(duì)同一個(gè)生成器跑了兩遍第二遍沒有數(shù)據(jù)。原因迭代器是單次消費(fèi)的。建議如果需要重復(fù)遍歷就把數(shù)據(jù)固化到列表/元組里或者每次都重新生成新的生成器。需要記住的是迭代器的設(shè)計(jì)初衷就是“流式數(shù)據(jù)的一次性消費(fèi)”不適合隨機(jī)訪問。7. 一些更高階的收尾經(jīng)驗(yàn)當(dāng)初我自己學(xué)這兩塊內(nèi)容時(shí)最深刻的感受是for和with都不僅僅是語法它們是 Python 設(shè)計(jì)哲學(xué)的具象化——通過統(tǒng)一的協(xié)議來約束行為進(jìn)而讓復(fù)雜的事情變得簡(jiǎn)單。掌握 for 語句的關(guān)鍵不只是語法層面更在于建立“迭代即消費(fèi)”的意識(shí)。數(shù)據(jù)是惰性的迭代是流式的內(nèi)存是寶貴的。在實(shí)際開發(fā)中你的一個(gè)列表推導(dǎo)式可能省了幾行代碼但你的一個(gè)生成器可能救活了整個(gè)跑批服務(wù)。掌握 with 語句的關(guān)鍵在于建立“生命周期”這個(gè)心智模型。每個(gè)資源都有自己的生命周期連接有開始和關(guān)閉鎖有獲取和釋放事務(wù)有提交和回滾。Python 的with讓你可以把這些生命周期成對(duì)地組織起來無論發(fā)生什么情況清理邏輯都必然執(zhí)行。這種確定性的資源管理方式在并發(fā)、系統(tǒng)編程、數(shù)據(jù)工程這些領(lǐng)域是穩(wěn)定性的基礎(chǔ)。最后再分享一個(gè)小技巧你在寫一個(gè)新的工具函數(shù)時(shí)如果發(fā)現(xiàn)這個(gè)函數(shù)開頭總是要做某類準(zhǔn)備結(jié)尾總是要做某類清理那不妨考慮把它做成上下文管理器。不需要太復(fù)雜contextlib.contextmanager裝飾器加一個(gè)yield就能搞定。我自己的很多工具庫里的資源管理代碼后來都是這樣一步步抽象出來的。它讓你寫業(yè)務(wù)代碼時(shí)只管核心邏輯而讓資源管理退居幕后默默兜底。進(jìn)階之路沒有捷徑但把這些底層機(jī)制理解透了回頭看一些復(fù)雜的框架代碼你會(huì)發(fā)現(xiàn)它們也不過是搭建在這些基礎(chǔ)語法之上的一套套“組織模式”。希望這篇內(nèi)容對(duì)你有用實(shí)踐中多寫多踩坑這些知識(shí)點(diǎn)才能真正變成你自己的武器。