Python自帶的ftplib模塊說它是標(biāo)準(zhǔn)庫里最容易被忽略的寶藏之一一點都不過分。很多新手學(xué)完os、re、requests之后遇到文件傳輸需求第一反應(yīng)是去找第三方庫但如果你只需要跟FTP服務(wù)器打交道ftplib完全夠用而且是零依賴、開箱即用。這篇文章我就拿實際使用的經(jīng)驗把ftplib的核心功能、常用的坑、以及一些業(yè)務(wù)場景下的封裝技巧一次講透適合那些剛?cè)腴TPython、需要對接FTP服務(wù)的開發(fā)同學(xué)也適合已經(jīng)用了一段時間但沒系統(tǒng)梳理過的朋友查漏補(bǔ)缺。1. 動手之前先把FTP協(xié)議的底子補(bǔ)上很多人直接拿ftplib當(dāng)普通的HTTP庫用結(jié)果遇到各種奇怪問題——明明能連上、登錄成功但一傳文件就卡住或者超時。問題大多出在沒搞懂FTP協(xié)議的工作方式上。1.1 一個協(xié)議兩條連接FTP和HTTP有個本質(zhì)區(qū)別HTTP只有一條連接請求響應(yīng)都在上面完成FTP是兩條獨立的連接一條叫控制連接一條叫數(shù)據(jù)連接?？刂七B接就是你執(zhí)行登錄、切換目錄、刪除文件這些命令時走的通道它是一條長連接一直開著。而真正傳輸文件內(nèi)容、拉取目錄列表的時候服務(wù)器會單獨開一條數(shù)據(jù)連接傳完就關(guān)閉。這兩條連接的端口還不一樣?？刂七B接默認(rèn)是21端口數(shù)據(jù)連接的端口則由傳輸模式?jīng)Q定。主動模式下服務(wù)器主動去連客戶端的某個端口被動模式下服務(wù)器告訴你一個端口號由客戶端去連接。這就是為什么很多FTP客戶端軟件里會有“主動模式”和“被動模式”的切換開關(guān)ftplib也一樣默認(rèn)為主動模式但實際使用中多數(shù)場景要改成被動模式。1.2 主動模式和被動模式怎么選主動模式下客戶端在控制連接上告訴服務(wù)器“我開放了某個端口你過來連接”然后服務(wù)器主動向客戶端發(fā)起數(shù)據(jù)連接。這個模式的問題很明顯——客戶端如果在內(nèi)網(wǎng)或者有防火墻服務(wù)器過不來數(shù)據(jù)傳輸就失敗了。被動模式下客戶端在控制連接上發(fā)送PASV命令服務(wù)器返回一個IP和端口由客戶端去連接。這種模式對客戶端更友好因為數(shù)據(jù)傳輸連接是客戶端主動發(fā)起的不會被防火墻攔截。我在實際項目中客戶端部署在云服務(wù)器上FTP服務(wù)器在另一臺機(jī)器上直接用默認(rèn)的主動模式就經(jīng)?？ㄋ栏某杀粍幽Ｊ胶髥栴}立刻消失。所以如果你發(fā)現(xiàn)連接正常、登錄也正常但一執(zhí)行下載或者列目錄就hang住優(yōu)先檢查是不是主動模式惹的禍。注意ftplib里設(shè)置被動模式很簡單FTP類的構(gòu)造參數(shù)里有個passive默認(rèn)是True也就是被動模式。如果你用的是默認(rèn)值還出現(xiàn)問題那就要從服務(wù)器配置或者網(wǎng)絡(luò)安全組層面去排查了。1.3 ftplib到底封裝了什么ftplib本身是標(biāo)準(zhǔn)庫它做的事情就是按照FTP協(xié)議的報文格式幫你把命令發(fā)出去、把響接收回來。你不需要關(guān)心底層socket怎么收發(fā)數(shù)據(jù)也不需要手工構(gòu)造FTP命令ftplib里的每個方法基本都對應(yīng)一個FTP命令。比如login()方法發(fā)送USER和PASScwd()方法發(fā)送CWDnlst()發(fā)送NLSTretrbinary()發(fā)送RETRstorbinary()發(fā)送STOR。理解了這層映射關(guān)系你去看ftplib的源碼時會覺得非常清晰出問題的時候也能通過抓包或者查看原始響應(yīng)來定位。2. ftplib的核心類與方法心智圖ftplib模塊里真正干活的主要是兩個類FTP和FTP_TLS。FTP_TLS是FTP的加強(qiáng)版增加了對TLS加密傳輸?shù)闹С帧Ｆ渌€有一些輔助類比如FTP_HOST、FTP_PORT等常量但日常用到的不多。2.1 FTP類的核心方法一覽先看一張梳理好的方法表不用背用到的時候回來查就行方法對應(yīng)FTP命令作用connect(host, port)無連接FTP服務(wù)器login(user, passwd)USER / PASS登錄認(rèn)證cwd(pathname)CWD切換工作目錄pwd()PWD返回當(dāng)前目錄nlst(dirname)NLST返回目錄下的文件名列表dir(dirname)LIST返回詳細(xì)目錄列表retrlines(cmd)LIST / NLST下載文本內(nèi)容retrbinary(cmd, callback)RETR以二進(jìn)制方式下載文件storbinary(cmd, fp)STOR以二進(jìn)制方式上傳文件storlines(cmd, fp)STOR以文本方式上傳文件delete(filename)DELE刪除文件rename(from, to)RNFR / RNTO重命名文件/目錄mkd(pathname)MKD創(chuàng)建目錄rmd(pathname)RMD刪除目錄size(filename)SIZE獲取文件大小sendcmd(cmd)任意命令發(fā)送原始FTP命令并返回響應(yīng)quit()QUIT發(fā)送退出命令并關(guān)閉連接close()無關(guān)閉連接但不發(fā)送QUITset_debuglevel(level)無設(shè)置調(diào)試輸出級別voidresp()無讀取并返回響應(yīng)數(shù)據(jù)這些方法里retrbinary、storbinary、nlst、dir是最高頻的四個下面逐個展開說。2.2 FTP_TLS該用加密的時候不要偷懶FTP_TLS是FTP的子類用法基本一致只是在連接階段多了一步TLS握手。這里有一個很容易混淆的點FTP_TLS支持兩種工作模式一種是顯式TLS客戶端連接后先發(fā)送AUTH TLS命令升級為加密通道這是RFC 4217標(biāo)準(zhǔn)定義的方式另一種是隱式TLS從建立連接開始就默認(rèn)使用TLS默認(rèn)端口通常是990。ftplib里的FTP_TLS默認(rèn)走顯式TLS也就是先connect再login就可以了。但如果服務(wù)器只支持隱式TLS你就需要額外指定一個參數(shù)。具體做法是直接用FTP_TLS.connect()連接時傳不同的端口并且通過設(shè)置ssl_version等參數(shù)來控制。不過說實話隱式TLS的場景相對少大多數(shù)企業(yè)內(nèi)部還是用顯式模式或者干脆直接用SFTP。用FTP_TLS還有一個很重要的細(xì)節(jié)執(zhí)行TLS握手后默認(rèn)情況下后續(xù)的數(shù)據(jù)連接也是加密的但有些服務(wù)器配置了只有在需要時才加密或者數(shù)據(jù)傳輸不加密。如果你發(fā)現(xiàn)retrbinary時報錯提示數(shù)據(jù)連接沒有加密或者SSL相關(guān)的問題可以在完成登錄后執(zhí)行一次prot_p()。2.3 連接對象的生命周期每次使用完FTP連接一定要記得關(guān)閉。很多人用with語句習(xí)慣了上下文管理的便利但ftplib的FTP類在Python 3.4之前并沒有實現(xiàn)__enter__和__exit__之后版本才補(bǔ)上。所以網(wǎng)上很多老代碼是try/finally寫法新代碼可以直接用with。另外FTP連接是有時效的服務(wù)器通常配置了空閑超時時間。如果連接長時間沒有動作服務(wù)器會自動斷開。這種情況最常出現(xiàn)在批量上傳任務(wù)的循環(huán)里處理完一個文件后隔了一段時間再處理下一個結(jié)果連接已經(jīng)斷了接著報錯。解決辦法有兩個要么在每次操作前調(diào)用voidcmd(NOOP)做一次心跳要么在任務(wù)循環(huán)里重新登錄。3. 實操從連接、上傳到下載的完整落地下面用一個完整的例子來演示ftplib的實戰(zhàn)流程。這個例子綜合了我平時處理FTP任務(wù)時的習(xí)慣寫法從連接、登錄、切換目錄到文件上傳和下載都有。3.1 基礎(chǔ)連接與登錄from ftplib import FTP, FTP_TLS ftp FTP() ftp.connect(host192.168.1.100, port21, timeout10) ftp.login(userusername, passwdpassword) print(ftp.pwd())這里connect和login分開寫好處是你可以更清晰地控制連接階段的超時。如果直接用FTP(host, user, passwd)方式構(gòu)造其實內(nèi)部也是先connect再login但超時時間只能用默認(rèn)的。connect的timeout參數(shù)很重要。默認(rèn)情況下如果不設(shè)置socket層面的超時時間可能是全局默認(rèn)有些環(huán)境下會非常長導(dǎo)致程序卡住很久才報錯。我一般都會顯式設(shè)置一個合理的timeout比如10秒或者15秒這樣網(wǎng)絡(luò)不通時能快速失敗。登錄成功后服務(wù)器會返回230狀態(tài)碼表示登錄成功如果用戶名密碼錯誤返回530。ftplib會把狀態(tài)碼和消息包裝成異常所以在實際使用中登錄失敗會直接拋異常你需要在外面捕獲并處理。3.2 目錄切換與列表獲取登錄之后第一步通常要切換目錄ftp.cwd(/pub/data/2024) print(ftp.pwd()) files ftp.nlst() print(files)nlst()返回的是不帶權(quán)限信息、不帶時間戳的文件名列表適合做自動化處理。但要注意有些服務(wù)器對NLST的支持不完全返回的格式可能不標(biāo)準(zhǔn)。如果代碼里需要判斷文件大小、修改時間等詳細(xì)信息就要用dir()或者retrlines(LIST)。我的習(xí)慣是如果是批量下載先用nlst拿到文件名列表然后逐個用size()方法查詢文件大小再決定是否下載。但size()方法依賴SIZE命令有些FTP服務(wù)器上的SIZE命令是被禁用的會報錯“SIZE not allowed in ASCII mode”之類。如果碰到這種情況直接下載即可別過度依賴size來做過濾。3.3 上傳文件兩種姿勢上傳文件最常用的是storbinary因為它以二進(jìn)制方式傳輸不會在傳輸過程中破壞文件內(nèi)容。這里說的“破壞”是真實存在的問題——如果用文本模式傳一個二進(jìn)制文件換行符會被自動轉(zhuǎn)換圖片、壓縮包傳過去就損壞了。import os local_path local_archive.zip remote_path /pub/data/2024/archive.zip with open(local_path, rb) as fp: ftp.storbinary(fSTOR {remote_path}, fp, blocksize8192)storbinary的第一個參數(shù)是完整的FTP傳輸命令通常是STOR 文件名。第二個參數(shù)是一個文件對象第三個參數(shù)是緩沖區(qū)大小默認(rèn)是8192字節(jié)。這個blocksize影響傳輸性能太小會導(dǎo)致頻繁socket讀寫太大則占用內(nèi)存。我試過8KB和64KB在小文件場景下區(qū)別不大傳大文件時64KB會快一點但8KB更穩(wěn)一些不會因為單次寫入過大導(dǎo)致對端緩沖區(qū)溢出。日常用默認(rèn)值即可。如果你想把一個內(nèi)存中的字符串上傳上去不需要先保存成臨時文件可以借助io.BytesIO把數(shù)據(jù)包裝成類文件對象from io import BytesIO data hello ftplib.encode(utf-8) bio BytesIO(data) ftp.storbinary(STOR /tmp/hello.txt, bio)這個技巧在處理動態(tài)生成的內(nèi)容時非常有用省去了臨時文件的創(chuàng)建和清理。3.4 下載文件二進(jìn)制和文本兩種讀取方式下載文件和上傳類似用到retrbinary。它的第二個參數(shù)是一個回調(diào)函數(shù)這個函數(shù)接收每次讀取到的chunk數(shù)據(jù)。最常見的寫法是把chunk寫入本地文件remote_path /pub/data/2024/archive.zip local_path local_archive.zip with open(local_path, wb) as fp: ftp.retrbinary(fRETR {remote_path}, fp.write, blocksize8192)注意這里直接傳了fp.write作為回調(diào)因為retrbinary每次讀到的chunk都是bytes而文件以二進(jìn)制模式打開write方法接收bytes完美匹配。如果是下載文本文件并直接在內(nèi)存中處理內(nèi)容不想落盤可以用retrlines加上自己的處理邏輯lines [] ftp.retrlines(fRETR /pub/data/2024/readme.txt, callbacklines.append) for line in lines: print(line)retrlines的callback接收到的是解碼后的字符串默認(rèn)按utf-8解碼你也可以通過encoding參數(shù)修改。需要注意retrlines會把行尾的\r\n去掉所以在拼接內(nèi)容重新寫文件時可能需要自己補(bǔ)回來。3.5 完整示例一個簡單的FTP備份腳本把上面這些拼起來就是一個比較完整的FTP備份腳本。下面這個例子模擬了一個實際的備份場景從本地目錄上傳文件到FTP服務(wù)器的某個路徑下并進(jìn)行簡單的錯誤處理。import os from ftplib import FTP from datetime import datetime def upload_backup(local_dir: str, remote_dir: str, host: str, user: str, passwd: str): ftp FTP() ftp.connect(host, port21, timeout15) ftp.login(user, passwd) ftp.set_debuglevel(0) # 確保遠(yuǎn)程目錄存在 try: ftp.cwd(remote_dir) except Exception: # 目錄不存在則逐級創(chuàng)建 current_path for part in remote_dir.strip(/).split(/): current_path f/{part} try: ftp.cwd(current_path) except Exception: ftp.mkd(current_path) ftp.cwd(current_path) for filename in os.listdir(local_dir): local_file os.path.join(local_dir, filename) if not os.path.isfile(local_file): continue with open(local_file, rb) as fp: ftp.storbinary(fSTOR {filename}, fp) print(fuploaded: {filename}) ftp.quit() print(backup finished at, datetime.now().isoformat()) if __name__ __main__: upload_backup( local_dir./data, remote_dir/backup/2024, host192.168.1.100, userftpuser, passwdftppass )這段代碼里有幾個實際常用的處理細(xì)節(jié)第一是遠(yuǎn)程目錄不存在時逐級創(chuàng)建因為mkd只能創(chuàng)建一層目錄第二是每次上傳后打印進(jìn)度方便觀察任務(wù)是否卡住第三是在結(jié)束時調(diào)用quit()而非close()這樣會正常發(fā)送QUIT命令服務(wù)器端也能及時釋放資源。3.6 斷點續(xù)傳的實現(xiàn)思路ftplib自身沒有直接提供斷點續(xù)傳的功能但實現(xiàn)起來也不復(fù)雜。核心就是REST命令加RETR命令的組合。REST命令告訴服務(wù)器從文件的某個偏移量開始傳輸然后RETR重新開始傳輸文件。import os from ftplib import FTP def resume_download(ftp: FTP, remote_path: str, local_path: str): # 獲取遠(yuǎn)程文件總大小 remote_size ftp.size(remote_path) local_size 0 if os.path.exists(local_path): local_size os.path.getsize(local_path) if local_size remote_size: # 從本地已有的偏移量開始續(xù)傳 ftp.sendcmd(fREST {local_size}) with open(local_path, ab) as fp: ftp.retrbinary(fRETR {remote_path}, fp.write) print(download resumed and completed) else: print(file already complete)這個示例是續(xù)傳下載斷點續(xù)傳上傳會麻煩一些因為需要服務(wù)器支持APPE命令或者用STOR配合REST來實現(xiàn)。很多服務(wù)器不支持REST上傳所以上傳斷點續(xù)傳的兼容性不如下載。實際場景中如果網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致上傳中斷我更推薦的做法是重新傳一遍或者用SFTP/rsync這類自帶斷點續(xù)傳與校驗功能的工具而不是強(qiáng)行在ftplib上做上傳續(xù)傳。4. 常見報錯與排查技巧實錄ftplib使用中碰到的報錯類型其實很有限核心就那么幾個異常類。搞明白這幾個異?；灸芙鉀Q九成的問題。4.1 異常類型速查異常類觸發(fā)場景常見原因ftplib.error_perm永久性錯誤530未登錄、550文件不存在或權(quán)限不足ftplib.error_temp臨時性錯誤421服務(wù)不可用、425無法建立數(shù)據(jù)連接ftplib.error_proto協(xié)議錯誤服務(wù)器返回不合法響應(yīng)socket.timeout超時網(wǎng)絡(luò)不通、被動模式端口被防火墻攔截ConnectionRefusedError連接被拒絕服務(wù)器端口未開放、IP錯誤error_perm是最常見的。如果你在調(diào)用方法時收到550 Failed to change directory.說明目標(biāo)目錄不存在或者你沒有權(quán)限進(jìn)入。這種錯誤通常是代碼邏輯和服務(wù)器配置之間不匹配排查方向就是確認(rèn)路徑和權(quán)限。425 Unable to build data connection: Connection refused是典型的主動/被動模式或防火墻問題。這時我第一件事是切被動模式試試。用ftp.set_pasv(True)設(shè)置被動模式后再調(diào)用下載方法大部分場景能直接解決。4.2 超時相關(guān)卡住不動怎么辦FTP連接卡住不返回原因往往是網(wǎng)絡(luò)層的半開連接。比如控制連接已經(jīng)建立但數(shù)據(jù)連接因為防火墻原因無法建立程序就hang在讀取socket響應(yīng)的地方。排查辦法很簡單開啟調(diào)試模式ftp.set_debuglevel(2)把這行加在連接成功之后再次執(zhí)行操作你會發(fā)現(xiàn)ftplib會把每次發(fā)送的命令和接收的響應(yīng)原樣打印出來。這時候看最后一條響應(yīng)是什么如果是227 Entering Passive Mode說明服務(wù)器已經(jīng)返回了被動模式的IP和端口但客戶端后續(xù)連接數(shù)據(jù)端口失敗。再看一下命令返回的IP是什么如果是一個內(nèi)網(wǎng)地址說明FTP服務(wù)器在NAT后面客戶端無法連接它返回的那個IP。這種情況就需要在服務(wù)器端配置正確的公網(wǎng)IP。每次定位FTP問題先用set_debuglevel(2)打開調(diào)試看報文比盲猜高效得多。這個方法簡單到幾乎不占成本但很多人就是不知道用。4.3 中文文件名亂碼問題中文文件名的顯示亂碼根源在于FTP協(xié)議本身沒有聲明文件名編碼。RFC 2640定義了UTF-8作為推薦的字符集但很多老舊服務(wù)器或者客戶端默認(rèn)用的還是GBK或Latin-1。在Python 3里ftplib處理響應(yīng)時默認(rèn)按latin-1解碼中文就變成亂碼了。ftplib從Python 3開始支持通過encoding參數(shù)指定編碼。你的FTP服務(wù)器如果是純UTF-8創(chuàng)建FTP對象時加上編碼參數(shù)ftp FTP(encodingutf-8)如果服務(wù)器用的是GBKftp FTP(encodinggbk)但更隱蔽的問題是目錄列表里的中文亂碼和文件名列表里的中文亂碼可能不是同一種編碼導(dǎo)致的。nlst()返回的文件名和dir()返回的詳細(xì)信息如果編碼判斷不一致需要分別處理。我遇到過一種情況是服務(wù)器在控制連接返回的文件名是UTF-8但LIST響應(yīng)里帶的時間格式卻是拉丁字符混在一起如果無腦用同一種編碼解反而會引發(fā)出錯。最穩(wěn)妥的做法是能設(shè)置編碼就設(shè)置編碼nlst()拿到的文件名還亂碼的話就自己寫一個底層命令交互用sendcmd和retrbinary手工控制編碼。5. 日常使用時的幾個進(jìn)階技巧掌握了基礎(chǔ)操作和常見排查ftplib已經(jīng)能解決大多數(shù)問題。但實際業(yè)務(wù)中總有些零碎的小技巧能讓代碼更簡潔、更健壯。5.1 用上下文管理器避免連接泄漏新版Python的ftplib已經(jīng)支持with語法。我強(qiáng)烈建議在任何臨時連接場景下使用from ftplib import FTP with FTP(192.168.1.100) as ftp: ftp.login(user, pass) ftp.cwd(/data) print(ftp.nlst())這樣即使中間拋異常連接也會被正確關(guān)閉避免程序的socket資源慢慢耗盡。如果你用的是老代碼風(fēng)格一定記得在finally里手工調(diào)用quit。5.2 批量任務(wù)中的連接復(fù)用批量處理大量文件時頻繁建立連接再斷開很浪費。更合理的方式是建立一個長連接循環(huán)里復(fù)用同時通過定時發(fā)送NOOP保持連接活躍。ftp FTP() ftp.connect(host192.168.1.100, port21, timeout30) ftp.login(user, pass) try: for remote_file in file_list: # 每次操作前發(fā)一個NOOP維持連接 ftp.voidcmd(NOOP) local_file download_one(ftp, remote_file) print(downloaded, local_file) finally: ftp.quit()這里的NOOP命令本身沒有副作用只用于檢測連接是否還活著。如果服務(wù)器已經(jīng)斷開連接發(fā)送NOOP會立刻拋異常你就可以在這個地方統(tǒng)一做重連處理而不是等到下載文件到一半才發(fā)現(xiàn)連接斷了。5.3 從內(nèi)存中直接上傳和下載前面提過用BytesIO配合storbinary實現(xiàn)內(nèi)存上傳。下載也可以不進(jìn)磁盤直接讀進(jìn)內(nèi)存from io import BytesIO buffer BytesIO() ftp.retrbinary(RETR /data/config.json, buffer.write) content buffer.getvalue().decode(utf-8) print(content)這個場景特別適合處理配置文件和接口數(shù)據(jù)傳輸。我在做自動化巡檢腳本時經(jīng)常需要拉取遠(yuǎn)程機(jī)器上的配置文件和別的服務(wù)器比對用這種方式完全不需要在本地創(chuàng)建臨時文件邏輯也更干凈。5.4 一鍵遞歸下載目錄ftplib沒有遞歸下載目錄的方法但遞歸本質(zhì)上是循環(huán)加?；蜿犃衒rom ftplib import FTP, error_perm import os def download_recursive(ftp: FTP, remote_dir: str, local_dir: str): stack [(remote_dir, local_dir)] while stack: rdir, ldir stack.pop() ftp.cwd(rdir) os.makedirs(ldir, exist_okTrue) for name in ftp.nlst(): rpath f{rdir}/{name} lpath os.path.join(ldir, name) if is_dir(ftp, rpath): stack.append((rpath, lpath)) else: with open(lpath, wb) as fp: ftp.retrbinary(fRETR {rpath}, fp.write)需要額外實現(xiàn)一個is_dir()判斷可以用size()方法是否拋異常來判斷是不是目錄——很多服務(wù)器對目錄執(zhí)行SIZE命令會報錯。這種方法在服務(wù)器對LIST響應(yīng)不一致的場景下比解析dir()的輸出要可靠得多。6. 安全與合規(guī)提醒FTP協(xié)議本身是明文傳輸用戶名密碼和數(shù)據(jù)內(nèi)容在傳輸過程中都是裸奔的。尤其在內(nèi)網(wǎng)環(huán)境下很多人覺得無所謂但我在實際項目里見過不止一次因為內(nèi)網(wǎng)被滲透導(dǎo)致FTP賬號密碼被截獲的事件。6.1 FTPS與SFTP的區(qū)別有人會把FTPS和SFTP搞混。FTPS是FTP over TLS也就是FTP協(xié)議本身加了一層SSL/TLS基礎(chǔ)還是FTP那套命令用ftplib的FTP_TLS就能實現(xiàn)。SFTP是基于SSH協(xié)議的文件傳輸協(xié)議端口通常走22Python里要用另一個第三方庫去實現(xiàn)比如paramiko。如果你能控制服務(wù)器端的選擇內(nèi)部文件傳輸我更推薦SFTP因為它天然復(fù)用SSH的認(rèn)證和加密體系密鑰管理和權(quán)限配置都更成熟。但如果服務(wù)器是傳統(tǒng)FTP服務(wù)不需要改造成本的情況下至少要用FTP_TLS把通信加密起來不能用裸FTP直接跑敏感數(shù)據(jù)。6.2 實際使用中的取舍建議從實踐經(jīng)驗來看ftplib適合以下場景對接老舊的FTP服務(wù)器服務(wù)器端無法改動協(xié)議內(nèi)部局域網(wǎng)、可信網(wǎng)絡(luò)環(huán)境下的簡單文件傳輸自動運(yùn)維腳本、定時備份任務(wù)需要精細(xì)控制FTP命令的探活和交互場景如果項目允許自由選擇技術(shù)棧并且對傳輸安全有較高要求還是優(yōu)先考慮SFTP或者對象存儲這類現(xiàn)代方案沒必要在FTP上硬扛。另外還要注意ftplib的性能天花板不高它的socket讀寫是阻塞式的處理單線程順序傳輸還行大規(guī)模并發(fā)傳輸會力不從心。如果業(yè)務(wù)要求同時傳輸大量文件需要引入線程池或者改用異步HTTP/對象存儲網(wǎng)關(guān)進(jìn)行中轉(zhuǎn)。7. 結(jié)尾補(bǔ)充一些實際經(jīng)驗我最初用ftplib的時候碰到一個特別隱蔽的問題服務(wù)器端的目錄列表里有個中文目錄名使用nlst()拿到的是正常字符串但當(dāng)我把它拼到下載路徑里后服務(wù)器報“550 No such file or directory”。后來打開調(diào)試模式才發(fā)現(xiàn)nlst()返回的字符串是已經(jīng)按照latin-1解碼過的而實際上原始字節(jié)是UTF-8編碼的中文拿到Python里再編碼回去就變成了另外一串字節(jié)服務(wù)器當(dāng)然找不到路徑。最后通過指定encodingutf-8解決了。這件事給我最大的教訓(xùn)就是——遇到ftplib和中文相關(guān)的問題先確認(rèn)服務(wù)器端和客戶端的編碼是不是一致再談其他。還有一次是批量上傳任務(wù)跑了幾個小時突然卡住我最初懷疑是網(wǎng)絡(luò)問題但后來發(fā)現(xiàn)是FTP服務(wù)器設(shè)置了空閑超時10分鐘沒有數(shù)據(jù)傳輸就自動斷開控制連接。從那以后我在所有長任務(wù)里都加了NOOP心跳再也沒有出現(xiàn)過類似問題。希望這篇文章能讓你少走一些彎路。如果你在項目里也遇到過ftplib相關(guān)的疑難問題不妨從編碼、被動模式、超時和心跳這幾個方向去排查大部分問題都逃不出這幾點。