說(shuō)實(shí)話很多人學(xué)了Python基礎(chǔ)語(yǔ)法之后第一個(gè)感覺自己會(huì)寫腳本了的時(shí)刻往往就是從文件操作開始的——批量改名、整理下載目錄、按日期歸檔日志。但也是從這一刻開始才真正體會(huì)到Python文檔里那三個(gè)庫(kù)的分家有多讓人迷惑操作文件用os處理路徑用os.path高級(jí)復(fù)制刪除又跳出來(lái)一個(gè)shutil到了Python 3.4之后還得加上pathlib。剛上手的時(shí)候我也是一頓混用同一個(gè)腳本里同時(shí)出現(xiàn)os.path.join和Path的情況比比皆是。這個(gè)主題看起來(lái)基礎(chǔ)實(shí)際上是幾乎所有自動(dòng)化腳本的地基。如果你能把os、pathlib、shutil這三者的分工和配合摸透后面寫爬蟲存數(shù)據(jù)、寫數(shù)據(jù)處理腳本、寫自動(dòng)部署工具都會(huì)非常順手。這篇文章我會(huì)直接按實(shí)際開發(fā)場(chǎng)景來(lái)拆不按文檔順序念重點(diǎn)講那些文檔里沒寫清楚、但你在真實(shí)工程里一定會(huì)撞上的問題。1. 三個(gè)庫(kù)三個(gè)脾氣先分清os、pathlib和shutil誰(shuí)負(fù)責(zé)哪攤活1.1 剛上手時(shí)最容易犯的錯(cuò)把所有文件操作都塞進(jìn)os里os模塊是Python和操作系統(tǒng)交互的最底層接口它的定位非常廣環(huán)境變量、進(jìn)程管理、工作目錄、文件描述符什么都有。正因?yàn)樗裁炊脊苣阒苯佑胦s去操作文件時(shí)寫出來(lái)的代碼往往很啰嗦。比如判斷一個(gè)路徑是不是文件、再拿到它的文件名最傳統(tǒng)的寫法是import os path /home/user/project/data/report_2024.csv if os.path.isfile(path): filename os.path.basename(path) dirname os.path.dirname(path) name, ext os.path.splitext(filename)這套API是早年C語(yǔ)言風(fēng)格的延續(xù)函數(shù)式、參數(shù)是字符串、返回也是字符串。你拼接路徑時(shí)得用os.path.join而且拼完之后得到的還是字符串后續(xù)想再取父目錄、改后綴名又得再調(diào)一層函數(shù)。邏輯一旦復(fù)雜起來(lái)滿屏的os.path.xxx嵌套讀起來(lái)非常累。1.2 pathlib的面向?qū)ο蟮降赘纳屏耸裁礀|西pathlib在Python 3.4引入它的核心思路很簡(jiǎn)單把路徑從字符串升級(jí)成對(duì)象。路徑不再是你要反復(fù)解析的原材料而是一個(gè)有方法、有屬性的實(shí)體。同樣是上面那段邏輯用pathlib寫是這樣from pathlib import Path path Path(/home/user/project/data/report_2024.csv) if path.is_file(): filename path.name dirname path.parent name path.stem ext path.suffix一眼就能看出差別path.name、path.parent、path.stem、path.suffix都是屬性不需要函數(shù)套函數(shù)。更關(guān)鍵的是Path對(duì)象重載了/運(yùn)算符拼接路徑可以寫成data_dir Path(project) / data / report_2024.csv這比os.path.join(project, data, report_2024.csv)直觀得多。而且Path對(duì)象在Windows和Linux上都能正確處理分隔符你不需要關(guān)心當(dāng)前系統(tǒng)是反斜杠還是正斜杠。1.3 shutil是真正干重活的那個(gè)os負(fù)責(zé)指出文件在哪、是什么pathlib負(fù)責(zé)優(yōu)雅地描述路徑而真正執(zhí)行把文件從一個(gè)地方搬到另一個(gè)地方把整個(gè)目錄樹復(fù)制走刪除整個(gè)目錄這類重體力活的是shutil。它全稱是shell utilities設(shè)計(jì)目標(biāo)就是補(bǔ)齊os模塊在文件級(jí)操作上的短板。舉幾個(gè)最常見的對(duì)比操作os系列shutil刪除單個(gè)文件os.remove(path)os.remove本身夠了刪除非空目錄os.rmdir只支持空目錄shutil.rmtree可以遞歸刪除復(fù)制單個(gè)文件os.system(cp ...)這種不推薦shutil.copy2(src, dst)復(fù)制整個(gè)目錄樹基本要自己寫遞歸shutil.copytree(src, dst)移動(dòng)文件os.rename跨目錄經(jīng)常報(bào)錯(cuò)shutil.move(src, dst)用多了你就會(huì)發(fā)現(xiàn)凡是涉及目錄樹級(jí)別或者跨文件系統(tǒng)的操作直接找shutil準(zhǔn)沒錯(cuò)。它內(nèi)部已經(jīng)把很多邊緣情況處理好了比如跨設(shè)備移動(dòng)會(huì)先復(fù)制再刪除不會(huì)像os.rename那樣直接拋OSError。1.4 為什么現(xiàn)在新代碼推薦你用pathlib而不是os.pathpathlib是Python 3.6以后官方文檔推薦的首選路徑處理方式原因不只是語(yǔ)法好看。它在設(shè)計(jì)上解決了一個(gè)很實(shí)際的問題路徑操作的組合性。字符串方式的os.path每一步函數(shù)返回的都是一個(gè)新的字符串你沒有一個(gè)穩(wěn)定的中間載體而Path對(duì)象本身就是一個(gè)載體你可以反復(fù)基于它做.parent、.joinpath()、.with_suffix()等操作代碼流程是連續(xù)的。當(dāng)然這不代表os沒用了。你要拿環(huán)境變量、要設(shè)置進(jìn)程工作目錄、要遍歷目錄樹拿底層文件描述符還是得用它。我的習(xí)慣是路徑描述和基本判斷用pathlib系統(tǒng)級(jí)交互用os文件批量操作用shutil。2. 路徑操作是最容易翻車的地方相對(duì)路徑、當(dāng)前目錄依賴病和不同操作系統(tǒng)的分隔符2.1 剛寫腳本時(shí)都犯過的病腳本一挪地方就找不到文件很多人寫腳本時(shí)圖省事直接用相對(duì)路徑with open(data/config.json, r) as f: config json.load(f)這段代碼能不能跑通完全取決于你運(yùn)行腳本時(shí)的工作目錄。如果你在項(xiàng)目根目錄運(yùn)行data/config.json能找到但如果你用IDE的調(diào)試功能、或者注冊(cè)成定時(shí)任務(wù)、或者從別的目錄調(diào)用這個(gè)腳本Python的當(dāng)前工作目錄變了這個(gè)相對(duì)路徑就立刻失效。報(bào)錯(cuò)往往是FileNotFoundError但你明明看到文件就在那里。正確的做法是基于腳本文件自身的位置來(lái)定位資源。pathlib提供了非常簡(jiǎn)單的方法from pathlib import Path BASE_DIR Path(__file__).resolve().parent config_path BASE_DIR / data / config.json__file__是當(dāng)前腳本文件的路徑.resolve()會(huì)把相對(duì)路徑轉(zhuǎn)成絕對(duì)路徑還能解析掉..和符號(hào)鏈接。之后無(wú)論你在哪個(gè)目錄下運(yùn)行這個(gè)腳本它都能找到自己旁邊的資源文件。這個(gè)習(xí)慣我從第二年開始就一直保持再也沒有被文件找不到這種低級(jí)問題坑過。2.2 相對(duì)路徑、絕對(duì)路徑和., ..這些隱藏陷阱Path(..)這類路徑看起來(lái)簡(jiǎn)單實(shí)際使用中很容易出問題。比如你想找項(xiàng)目根目錄下的某個(gè)文件從子目錄往上一級(jí)兩級(jí)path Path(__file__).resolve().parent.parent / config.yaml這里連續(xù)兩個(gè).parent取決于你的目錄層級(jí)。一旦中間目錄結(jié)構(gòu)調(diào)整這個(gè)路徑就失效了。更穩(wěn)妥的辦法是從項(xiàng)目根開始往下找# 假設(shè)倉(cāng)庫(kù)結(jié)構(gòu)repo/src/tools/gen_report.py # 要找 repo/config.yaml ROOT Path(__file__).resolve().parent.parent # 回到repo config_path ROOT / config.yaml另一個(gè)常見問題是.resolve()和.absolute()的區(qū)別。雖然兩者絕大多數(shù)時(shí)候結(jié)果相同但.resolve()會(huì)額外解析符號(hào)鏈接和..把路徑洗成最直接的形式.absolute()則不會(huì)處理符號(hào)鏈接只是單純把相對(duì)路徑補(bǔ)全成絕對(duì)路徑。在大多數(shù)場(chǎng)景下直接用.resolve()更可靠。2.3 Windows路徑分隔符反斜杠那些反直覺的事Windows的路徑是用反斜杠分隔的比如C:\Users\name\Documents\file.txt。在Python字符串里反斜杠是轉(zhuǎn)義符所以你寫Windows路徑時(shí)要么寫成C:\\Users\\name要么寫原始字符串rC:\Users\name。用os.path.join或者pathlib的/運(yùn)算符本質(zhì)上是讓庫(kù)去處理分隔符差異。這里有個(gè)很坑的細(xì)節(jié)你用pathlib在Windows上拼路徑時(shí)得到的Path對(duì)象打印出來(lái)默認(rèn)是反斜杠樣式但如果你把它轉(zhuǎn)成字符串傳給其他程序某些程序只認(rèn)正斜杠。一個(gè)常見的處理是path_str str(Path(data) / file.txt).replace(\\, /)還有一個(gè)更隱蔽的問題路徑中帶有空格?？崭裨诖蠖鄶?shù)情況下沒問題但一旦你把路徑拼進(jìn)命令字符串比如用subprocess調(diào)用外部命令就必須加引號(hào)否則命令會(huì)斷掉。用pathlib的resolve()通常能拿到絕對(duì)路徑但在拼命令時(shí)還是得手動(dòng)處理空格。2.4 中文文件名和Unicode規(guī)范化問題中文文件名在現(xiàn)代Python 3中基本沒有障礙路徑可以直接用中文字符串。但如果你處理的文件是別人上傳的文件名來(lái)源五花八門可能會(huì)出現(xiàn)Linux的UTF-8編碼和macOS的NFC/NFD規(guī)范化不一致的問題。具體表現(xiàn)是你用Path(報(bào)告.pdf)去匹配明明文件存在但if path.exists()返回False。這是因?yàn)閙acOS的文件系統(tǒng)用NFD分解形式存儲(chǔ)文件名而很多其他系統(tǒng)用NFC組合形式兩者從視覺上看一模一樣但編碼字節(jié)不同。如果你需要處理這類場(chǎng)景可以考慮用第三方庫(kù)unicodedata做規(guī)范化對(duì)齊或者干脆用模糊匹配。不過說(shuō)實(shí)話我自己遇到最多的還是Windows共享文件夾里的中文路徑這時(shí)基本上直接用pathlib也能搞定真正麻煩的是跨系統(tǒng)共享時(shí)編碼不一致。3. 目錄遍歷與文件篩選不靠記憶寫遞歸靠這三招掃目錄3.1 os.walk是全能但啰嗦的老牌選手批量處理文件時(shí)最常做的事就是把目錄樹整個(gè)逛一遍。os.walk是Python里最傳統(tǒng)的做法它會(huì)遞歸遍歷目錄每到一個(gè)目錄都返回三個(gè)值當(dāng)前目錄路徑、子目錄列表、文件列表。經(jīng)典用法import os for root, dirs, files in os.walk(/home/user/project): for name in files: if name.endswith(.log): full_path os.path.join(root, name) print(full_path)這套寫法本身沒問題但你可以看到root、dirs、files是三組平行的數(shù)據(jù)結(jié)構(gòu)你需要自己去os.path.join拼完整路徑。遍歷過程中如果想改變dirs的值來(lái)控制要不要進(jìn)入某個(gè)子目錄也容易出錯(cuò)。3.2 pathlib的glob和rglob讓遍歷變得優(yōu)雅很多pathlib自帶的glob和rglob是替代方案。我最常用的是rglob它的意思是遞歸地匹配glob模式from pathlib import Path base Path(/home/user/project) for path in base.rglob(*.log): print(path)注意rglob(*.log)匹配的是文件名以.log結(jié)尾的所有層級(jí)的文件返回的直接就是Path對(duì)象不需要手動(dòng)拼接。如果想匹配任意子目錄下的特定文件還可以寫# 匹配所有子目錄下的data.txt for path in base.rglob(data.txt): pass # 匹配兩層以內(nèi)的目錄結(jié)構(gòu) for path in base.glob(*/*/*.log): pass # 匹配所有文件不管擴(kuò)展名 for path in base.rglob(*): if path.is_file(): pass3.3 glob模式里那些微妙語(yǔ)法*、**、?和字符集glob模式本質(zhì)上是一種簡(jiǎn)化版的正則表達(dá)式不是完整的正則。最容易混淆的是*和***.log匹配當(dāng)前目錄下所有以.log結(jié)尾的文件*不跨目錄層級(jí)**/*.log在glob方法里可以跨層級(jí)匹配在rglob里寫**/*.log和直接寫*.log效果其實(shí)相同因?yàn)閞glob本身就是遞歸的?匹配單個(gè)任意字符比如report_?.csv能匹配report_1.csv但匹配不到report_10.csv[0-9]字符集匹配比如file_[0-9].txt我個(gè)人在實(shí)際項(xiàng)目中更傾向于用rglob加寬泛的匹配條件然后在循環(huán)里用Path對(duì)象的屬性做二次篩選。這樣比精心編寫glob模式更易讀也更好維護(hù)。3.4 按擴(kuò)展名、修改時(shí)間、文件大小篩文件的完整套路真正篩選文件時(shí)很少只靠擴(kuò)展名一種條件。比如清理超過30天的日志文件保留最近3天的備份找出大于100MB的臨時(shí)文件。pathlib做這類組合篩選非常順手import time from pathlib import Path base Path(/var/logs) cutoff time.time() - 30 * 24 * 60 * 60 # 30天前的時(shí)間戳 for path in base.rglob(*.log): if not path.is_file(): continue mtime path.stat().st_mtime if mtime cutoff: print(f可以清理: {path}大小: {path.stat().st_size / 1024:.1f} KB)path.stat()拿到的st_mtime是最后修改時(shí)間戳st_size是字節(jié)數(shù)。如果文件很多可以按大小倒序排優(yōu)先處理大文件files [p for p in base.rglob(*) if p.is_file()] files.sort(keylambda p: p.stat().st_size, reverseTrue) for p in files[:10]: print(f{p} ({p.stat().st_size / 1024 / 1024:.2f} MB))這里要注意的是p.stat()每次都會(huì)發(fā)起一次系統(tǒng)調(diào)用如果文件列表特別長(zhǎng)性能會(huì)明顯下降。對(duì)于幾千個(gè)文件這個(gè)量級(jí)沒什么問題但如果上百萬(wàn)文件建議先os.scandir拿底層數(shù)據(jù)再篩。4. 復(fù)制、移動(dòng)、重命名、刪除shutil高頻操作里的異?，F(xiàn)場(chǎng)4.1 拒絕訪問os error 5到底哪來(lái)的這個(gè)錯(cuò)誤基本是Windows環(huán)境專屬但它出現(xiàn)的原因五花八門。最常見的是目標(biāo)文件被另一個(gè)進(jìn)程鎖住了。比如你用Excel打開了某個(gè)xlsx文件然后腳本要去覆蓋它Windows會(huì)直接拒絕報(bào)PermissionError: [Errno 13] Permission denied有時(shí)候錯(cuò)誤信息里會(huì)帶os error 5。Linux下對(duì)應(yīng)的是權(quán)限位不足但Windows下更多是文件占用。還有一種情況是目標(biāo)目錄沒有寫權(quán)限。比如把文件復(fù)制到C:\Program Files這種系統(tǒng)受保護(hù)目錄普通權(quán)限下會(huì)被拒絕。解決辦法有兩種思路如果是文件被占用先找到占用進(jìn)程并關(guān)閉它或者讓腳本自動(dòng)重試如果是權(quán)限不足需要以管理員身份運(yùn)行或者修改目標(biāo)目錄的ACL我給個(gè)實(shí)用的重試封裝import shutil import time from pathlib import Path def copy_with_retry(src: Path, dst: Path, retries: int 5, delay: float 1.0): for i in range(retries): try: shutil.copy2(src, dst) return except PermissionError: if i retries - 1: raise time.sleep(delay) print(f目標(biāo)文件被占用第{i2}次嘗試復(fù)制...)這個(gè)函數(shù)在文件被Excel或其他程序短暫占用時(shí)很管用比如從共享目錄批量拉取文件時(shí)Office套件常常短暫鎖定文件。4.2 shutil.copy、copy2、copyfile三兄弟的區(qū)別shutil提供三個(gè)復(fù)制函數(shù)很多人不清楚差異直接導(dǎo)致復(fù)制出來(lái)的文件缺失元數(shù)據(jù)。它們的區(qū)別如下函數(shù)復(fù)制內(nèi)容是否保留權(quán)限是否保留時(shí)間戳目標(biāo)可以是目錄shutil.copyfile只復(fù)制文件內(nèi)容否否否shutil.copy文件內(nèi)容 權(quán)限部分否是shutil.copy2文件內(nèi)容 權(quán)限 元數(shù)據(jù)是是是我的經(jīng)驗(yàn)是絕大多數(shù)場(chǎng)景直接用copy2因?yàn)樗M量保留文件的修改時(shí)間和訪問時(shí)間在備份、歸檔類腳本里非常重要。如果備份后還需要用類似rsync的思路對(duì)比文件差異時(shí)間戳的存在能省去很多麻煩。copyfile適合那種只要內(nèi)容、別的都不管的極端場(chǎng)景。還要注意copy2和copy都允許dst參數(shù)是一個(gè)目錄這時(shí)會(huì)保留原始文件名而copyfile要求dst必須是完整的文件路徑。4.3 shutil.move跨目錄和跨文件系統(tǒng)時(shí)的行為差異shutil.move是移動(dòng)文件的推薦函數(shù)但它內(nèi)部邏輯會(huì)讓很多人困惑文件在同一個(gè)文件系統(tǒng)內(nèi)時(shí)它直接調(diào)用os.rename速度快但跨文件系統(tǒng)時(shí)它會(huì)先復(fù)制再刪除速度慢而且需要臨時(shí)空間。一個(gè)容易踩的坑是shutil.move的dst參數(shù)如果是已存在的目錄文件會(huì)被移進(jìn)這個(gè)目錄如果是一個(gè)文件路徑那就是重命名。寫代碼時(shí)最好明確意圖from pathlib import Path import shutil src Path(/tmp/data/report.csv) target_dir Path(/backup/2024/) target_dir.mkdir(parentsTrue, exist_okTrue) # 明確要移動(dòng)到目錄中 shutil.move(str(src), str(target_dir / src.name))另一個(gè)常見問題是目標(biāo)目錄不存在。shutil.move不會(huì)自動(dòng)創(chuàng)建目標(biāo)目錄如果目標(biāo)路徑的父目錄不存在它會(huì)拋FileNotFoundError。所以移動(dòng)之前一定要先mkdir(parentsTrue, exist_okTrue)。4.4 批量重命名時(shí)如何保住文件安全先演練再動(dòng)手批量重命名是文件操作腳本里最容易翻車的場(chǎng)景。我吃過最大的虧是重命名時(shí)新舊文件名有交叉處理到一半文件已經(jīng)改名了后續(xù)的源文件路徑失效。核心原則有兩條先把所有操作列成計(jì)劃再統(tǒng)一執(zhí)行執(zhí)行前檢查是否有重名沖突代碼可以這樣寫from pathlib import Path base Path(/home/user/photos) rename_plan [] for path in base.glob(IMG_*.jpg): # 假設(shè)要把 IMG_00123.jpg 改成 2024_00123.jpg new_name 2024_ path.name[4:] new_path path.with_name(new_name) if new_path.exists(): print(f跳過目標(biāo)已存在: {new_path}) continue rename_plan.append((path, new_path)) # 統(tǒng)一執(zhí)行 for old_path, new_path in rename_plan: old_path.rename(new_path) print(f{old_path.name} - {new_path.name})這里的關(guān)鍵是用path.with_name()生成同名目錄下的新文件名比手動(dòng)拼接父路徑靠譜得多。另外建議在重命名前先打印所有計(jì)劃給自己一個(gè)最后檢查的機(jī)會(huì)。搞批量操作時(shí)寧可慢一點(diǎn)也別一股腦跑完再發(fā)現(xiàn)全亂了。4.5 刪除操作的后悔藥別直接rmtree大多數(shù)人刪除文件時(shí)直接os.remove或shutil.rmtree這當(dāng)然沒問題但我在處理重要數(shù)據(jù)時(shí)習(xí)慣先做一個(gè)軟刪除把文件移動(dòng)到臨時(shí)回收目錄而不是直接刪。這樣萬(wàn)一手滑刪錯(cuò)了還能救回來(lái)。import shutil from pathlib import Path TRASH_DIR Path(/home/user/.trash) TRASH_DIR.mkdir(exist_okTrue) def safe_delete(path: Path): dst TRASH_DIR / path.name # 如果回收站已有同名文件加時(shí)間戳避免覆蓋 if dst.exists(): dst TRASH_DIR / f{path.stem}_{path.stat().st_mtime}{path.suffix} shutil.move(str(path), str(dst))這個(gè)軟刪除策略配合定時(shí)清理腳本既安全又不會(huì)讓回收站無(wú)限膨脹。特別是批量清理日志、臨時(shí)文件時(shí)強(qiáng)烈建議先軟刪除觀察幾天確認(rèn)沒問題再物理清除。5. 讀寫文件時(shí)的編碼與內(nèi)容處理亂碼不只是加個(gè)encoding那么直白5.1 用Path.open還是open以及with語(yǔ)句的必要性讀寫文件最簡(jiǎn)單的方式是內(nèi)置的open()但如果你已經(jīng)在用pathlib處理路徑直接用Path.open()會(huì)更統(tǒng)一from pathlib import Path path Path(report.txt) # 寫法一open函數(shù)字符串路徑 with open(report.txt, r, encodingutf-8) as f: content f.read() # 寫法二Path.open with path.open(r, encodingutf-8) as f: content f.read()兩者其實(shí)沒本質(zhì)區(qū)別Path.open就是幫你把路徑轉(zhuǎn)成字符串再調(diào)內(nèi)置open。真正要強(qiáng)調(diào)的是with語(yǔ)句。忘了with會(huì)導(dǎo)致文件句柄不釋放Windows上最直接的后果就是文件被占用、后面想刪都刪不掉。這也是很多os error 5的根源之一腳本運(yùn)行完進(jìn)程還在文件句柄還占著后續(xù)操作全失敗。5.2 Python 3的open默認(rèn)編碼為何會(huì)坑你Python 3里open()打開文本文件時(shí)默認(rèn)編碼取決于系統(tǒng)區(qū)域設(shè)置。Windows中文系統(tǒng)通常是gbkLinux通常是utf-8。這意味著同樣一段代碼在Windows上可以正常讀中文文件但部署到Linux上可能直接拋UnicodeDecodeError。最穩(wěn)妥的做法是每次打開文本文件都顯式指定encodingutf-8除非你能確定文件確實(shí)不是UTF-8。對(duì)中文環(huán)境來(lái)說(shuō)老系統(tǒng)傳下來(lái)的txt文件經(jīng)常會(huì)帶著GBK編碼處理這些文件時(shí)需要格外小心可能在讀取時(shí)就得指定encodinggbk。判斷文件實(shí)際編碼推薦用chardet庫(kù)做個(gè)初步猜測(cè)import chardet def detect_encoding(path): raw path.read_bytes()[:4096] result chardet.detect(raw) return result[encoding] or utf-8注意chardet不是百分百準(zhǔn)確尤其是對(duì)短文本。我的做法是先嘗試utf-8失敗后回退到gbk再不行才用chardet。5.3 BOMUTF-8文件里藏著的三個(gè)不可見字符另一個(gè)高頻坑是UTF-8 BOM。某些Windows程序特別是老版記事本保存UTF-8文件時(shí)會(huì)在文件開頭寫入一個(gè)\xef\xbb\xbf的BOM標(biāo)記。Python讀取時(shí)如果不處理字符串開頭會(huì)包含這個(gè)不可見字符導(dǎo)致if content.startswith(---)這種判斷失效。修復(fù)方法很簡(jiǎn)單用utf-8-sig編碼讀取with path.open(r, encodingutf-8-sig) as f: content f.read()utf-8-sig讀取時(shí)會(huì)自動(dòng)跳過開頭的BOM。但要注意寫入時(shí)用不用utf-8-sig要看你的下游工具。如果文件是給新程序用的用utf-8就行別主動(dòng)加BOM如果是給老Windows程序用加BOM反而保險(xiǎn)。5.4 大文件別用read()一次性讀完搞懂緩沖區(qū)新手最容易犯的錯(cuò)是讀大文件時(shí)直接read()一個(gè)幾GB的日志文件能把內(nèi)存撐爆。正確的做法是逐行迭代with path.open(r, encodingutf-8) as f: for line in f: # 處理每一行 process_line(line)如果文件不是按行組織、需要按固定塊讀可以用read(size)with path.open(rb) as f: # 二進(jìn)制模式 while chunk : f.read(8192): process_chunk(chunk)這里8192是經(jīng)典的緩沖區(qū)大小。如果你的腳本頻繁讀寫大量小文件還有一個(gè)性能優(yōu)化點(diǎn)把多個(gè)文件的讀寫邏輯合并減少系統(tǒng)調(diào)用次數(shù)。比如需要批量改文件內(nèi)容時(shí)不要每改一個(gè)就開關(guān)一次文件句柄先全部讀取到內(nèi)存中處理完再一次寫回。6. 生產(chǎn)環(huán)境里的防御式文件操作異常層次、競(jìng)態(tài)與健壯代碼風(fēng)格6.1 異常金字塔FileNotFoundError、PermissionError和OSError的家族關(guān)系文件操作最常見的異常有三個(gè)FileNotFoundError、PermissionError、IsADirectoryError。它們都是OSError的子類這是理解異常捕獲邏輯的關(guān)鍵。try: shutil.copy2(src, dst) except FileNotFoundError: print(f源文件不存在: {src}) except PermissionError: print(f沒有權(quán)限訪問: {src} 或 {dst}) except OSError as e: print(f其他操作系統(tǒng)級(jí)錯(cuò)誤: {e})捕獲順序是從具體到一般。如果你先寫except OSError后面的FileNotFoundError分支永遠(yuǎn)走不到。我見過不少同事在這個(gè)順序上栽跟頭。6.2 先檢查再操作的競(jìng)態(tài)問題文件在兩次調(diào)用之間可能消失很多新手習(xí)慣這樣寫if path.exists(): path.unlink()這個(gè)寫法有一個(gè)微妙的競(jìng)態(tài)問題exists()和unlink()之間文件可能被其他進(jìn)程刪掉或者新建。如果文件在這兩步之間消失unlink()會(huì)拋FileNotFoundError。生產(chǎn)環(huán)境下的文件操作永遠(yuǎn)要假設(shè)文件系統(tǒng)是動(dòng)態(tài)的。更好的做法是直接操作捕獲異常這就是Python提倡的EAFP風(fēng)格Easier to Ask for Forgiveness than Permissiontry: path.unlink() except FileNotFoundError: pass # 文件本來(lái)就不存在目的已達(dá)到這種風(fēng)格寫起來(lái)更健壯也減少了系統(tǒng)調(diào)用次數(shù)。同理創(chuàng)建目錄時(shí)用mkdir(parentsTrue, exist_okTrue)而不是先判斷exists()再?zèng)Q定要不要?jiǎng)?chuàng)建。6.3 冪等操作設(shè)計(jì)讓腳本可以放心跑第二次所謂冪等是指執(zhí)行一次和執(zhí)行兩次效果相同。日志清理腳本、備份腳本、臨時(shí)文件整理腳本都應(yīng)該設(shè)計(jì)成冪等的否則你第二次運(yùn)行時(shí)會(huì)因?yàn)槲募呀?jīng)不存在而出錯(cuò)。以清理超過30天的緩存文件為例import shutil import time from pathlib import Path CACHE_DIR Path(/tmp/myapp_cache) CLEAN_BEFORE time.time() - 30 * 24 * 60 * 60 if not CACHE_DIR.exists(): exit(0) for path in CACHE_DIR.rglob(*): try: if path.is_file() and path.stat().st_mtime CLEAN_BEFORE: path.unlink() print(f清理: {path}) elif path.is_dir() and path.stat().st_mtime CLEAN_BEFORE: shutil.rmtree(path, ignore_errorsTrue) except FileNotFoundError: # 如果在判斷和刪除之間文件被別人清了直接忽略 pass注意ignore_errorsTrue這個(gè)參數(shù)它會(huì)讓rmtree忽略文件不存在、權(quán)限不足等問題非常適合冪等清理場(chǎng)景。當(dāng)然也要注意別因?yàn)閕gnore_errors掩蓋了真正的問題在重要操作里還是顯式處理異常比較好。6.4 網(wǎng)絡(luò)共享目錄那些讓人抓狂的延遲和占用處理Windows共享目錄或NAS掛載點(diǎn)時(shí)文件操作會(huì)表現(xiàn)出一些本地目錄沒有的問題網(wǎng)絡(luò)延遲導(dǎo)致操作超時(shí)、文件被其他用戶鎖定、路徑訪問時(shí)斷時(shí)續(xù)。我的經(jīng)驗(yàn)是對(duì)網(wǎng)絡(luò)路徑的操作要合理地重試但絕不能無(wú)限重試。上面那個(gè)copy_with_retry模式再擴(kuò)展一下加上超時(shí)上限和日志輸出就能變成可靠的生產(chǎn)代碼。另外網(wǎng)絡(luò)路徑上盡量別用shutil.rmtree文件太多時(shí)可能異常緩慢優(yōu)先考慮分批刪除。6.5 實(shí)操收尾我個(gè)人的文件操作代碼習(xí)慣寫了這么多年文件操作腳本總結(jié)了幾條自己一直堅(jiān)持的習(xí)慣第一所有腳本開頭都用Path(__file__).resolve().parent定位基準(zhǔn)目錄絕不依賴運(yùn)行時(shí)的當(dāng)前工作目錄。第二所有文本讀寫都顯式指定編碼utf-8為默認(rèn)特殊情況再說(shuō)。第三所有批量操作先打印計(jì)劃再執(zhí)行寧可多花五秒看輸出也不要一失手刪掉一堆文件。第四所有刪除操作都先軟刪除到回收目錄觀察幾天再物理清除。這幾條習(xí)慣沒有一條是高級(jí)技巧但每一條都幫我在真實(shí)項(xiàng)目里避免過災(zāi)難性的故障。文件操作這活看著簡(jiǎn)單出的問題往往是最隱蔽、最難以恢復(fù)的——文件刪了可以重新下載但配置覆蓋錯(cuò)了可能直接讓服務(wù)起不來(lái)。拿捏好os、pathlib、shutil這三個(gè)庫(kù)的分工再把這些防御式的習(xí)慣融入代碼里你寫的文件處理腳本就能從本地跑通升級(jí)成生產(chǎn)可靠。