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