簡介面向需要在桌面客戶端中實現(xiàn)FTP上傳和實時進度反饋的.NET開發(fā)者這份C#實例完整演示了基于FTP協(xié)議分塊傳輸文件、按已上傳與總字節(jié)數比例計算進度的實現(xiàn)方式適合C#入門學習及需要快速集成的項目參考。項目采用WinForms窗體搭建覆蓋建立連接、身份認證、工作目錄切換、調用STOR命令上傳及回調更新進度條等關鍵環(huán)節(jié)并在UpLoadFiles模塊中集中了上傳與進度計算邏輯便于提取復用。資源包共35個文件壓縮后僅78KB核心為12個cs源文件輔以resources/resx界面資源、sln/csproj/config配置以及exe等編譯產物目錄結構清晰可直接按窗體或工具類模塊查閱。已有868人學習下載。其中UpLoadFiles模塊里的上傳進度計算、異常處理與重試思路以及對網絡延遲、文件大小限制、權限異常等常見問題的應對策略均可遷移到實際項目中省去底層協(xié)議調試時間提升上傳交互體驗。1. FTP上傳帶進度條一份能真實反饋傳輸狀態(tài)的完整實例如果你在找 FTP 上傳帶進度條的代碼而不是那種靠 Timer 滾動出來的假進度——這份實例可以直接照著做一個能用的工具。它基于 C# WinForm 實現(xiàn)用 FtpWebRequest 做協(xié)議層請求BackgroundWorker 做后臺任務進度條顯示的是真實寫入的字節(jié)數傳多少顯示多少失敗就停在原地不會出現(xiàn)“進度到 100% 文件卻沒到”的經典假象。適合三類人需要給公司做文件上報、數據分發(fā)工具的開發(fā)者剛接觸 FtpWebRequest 想直接抄代碼的新手以及被假進度條坑過、想徹底改掉這個壞習慣的運維。下文從請求鏈路講起逐步落到可運行的完整實現(xiàn)。提示這份資源是一套可運行的 C# WinForm 工程源碼核心功能就一個——把本地文件通過 FTP 傳到服務器并且全程顯示真實進度。2. FtpWebRequest 上傳鏈路先看清請求模型和進度數據從哪來2.1 一次上傳請求的完整生命周期控制連接與數據連接的分工FTP 和 HTTP 最大的區(qū)別在于FTP 有兩條獨立的通道?？刂七B接負責傳指令USER、PASS、STOR、QUIT 這些數據連接才是真正搬運文件字節(jié)內容的管道。FtpWebRequest 雖然把這兩條通道封裝成了一個對象但它底層做的工作并沒有變——理解這一點能幫你省下大量查日志的時間。一次完整的 FtpWebRequest.UploadFile 請求內部大致按這個順序執(zhí)行建立到服務器 21 端口的 TCP 控制連接發(fā)送 USER、PASS 完成身份認證對應的是你設置的 Credentials根據 UsePassive 屬性決定數據通道的建立方式——被動模式PASV是客戶端主動連接服務器開放的數據端口主動模式PORT是服務器回頭連你的客戶端。公網、內網穿透、帶防火墻的環(huán)境基本都推薦被動模式發(fā)送 STOR 命令向服務器聲明“我要上傳這個文件”文件名就是 URL 里最后一個路徑段數據通道建立后客戶端把文件字節(jié)流寫入 GetRequestStream() 拿到的 Stream寫完后關閉數據連接服務器返回 226 Transfer complete 確認收完如果沒設 KeepAlivefalse控制連接還會保持一段時間方便你繼續(xù)發(fā)下一條命令。這套流程能解釋絕大部分上傳問題。你看到請求拋異常先按返回碼定位530 是認證失敗550 是文件操作不合法425/426 是數據通道建立失敗。我見過不少人把這幾類錯誤混為一談?chuàng)Q了半天服務器配置最后發(fā)現(xiàn)只是賬號密碼不對。選被動還是主動在真實環(huán)境里經常是個玄學問題。公司出網防火墻一般只放行出站連接主動模式的 PORT 命令要求服務器回連你客戶端的隨機端口大概率被防火墻攔掉。所以現(xiàn)代 FTP 客戶端默認都是被動模式。但被動模式下服務器開放的臨時數據端口范圍如果被服務端防火墻限制得很窄又會出現(xiàn)控制連接秒開、數據通道超時的怪象。這種問題排查起來最像玄學——換一個端口范圍就好了。總之FtpWebRequest 里設 UsePassivetrue 的同時最好讓 FTP 服務端把被動端口范圍放寬并固定下來日志里看到 Entering Passive Mode 時能對得上端口區(qū)間就知道該去哪里查了。2.2 進度數據從哪來Stream 層的字節(jié)計數是唯一可靠來源進度條的本質是“已上傳字節(jié)數”除以“總字節(jié)數”。想拿到這個可靠數據必須在文件字節(jié)流這一層數數——也就是你自己負責讀本地文件再寫入請求流每一步記錄累加值。很多圖省事的人直接調 UploadFile 這類一鍵方法內部把整個文件吞進去你拿不到中間狀態(tài)進度條就只能靠猜。所以我在這個工程里刻意把“讀”和“寫”拆開用循環(huán)一塊一塊地搬// 手動讀取本地文件寫入FTP請求流每塊記錄一次進度 using (FileStream fs File.OpenRead(localPath)) using (Stream requestStream request.GetRequestStream()) { byte[] buffer new byte[64 * 1024]; // 緩沖區(qū)大小64KB int bytesRead; long total 0; while ((bytesRead fs.Read(buffer, 0, buffer.Length)) 0) { requestStream.Write(buffer, 0, bytesRead); total bytesRead; // 這里的total就是真實進度 progress?.Report(total); } }緩沖區(qū)大小是個折中選擇64KB 內存占用小進度刷新粒度又足夠平滑。要是設成 4MB大文件下進度條是幾秒一跳的頓挫感設成 512B網絡小包暴增服務器 CPU 也會被無謂消耗。另一個關鍵點是 total 必須在 Write 之后立即累加。這樣即使某次寫失敗進度條停留的位置也是真實已經推到網絡上的位置不會出現(xiàn)“顯示到了、數據沒到”的偏差。還有一個容易被忽略的細節(jié)GetRequestStream() 返回的流綁定著 FTP 數據通道狀態(tài)不能用 Stream.CopyTo 這類快捷方式。CopyTo 內部替你讀了寫、寫了讀但你插不上手數數。要么拆開循環(huán)自己累加要么給流套一層帶回調的包裝流。前者代碼直觀后者侵入性好但調試麻煩。對于一個小工具來說手動循環(huán)最劃算。另外手工循環(huán)還有一個額外好處天然支持速度統(tǒng)計。循環(huán)里記錄每次 Write 的耗時用 bytesRead 除以耗時就得到實時速率。假進度方案根本做不了這個功能因為它和網絡傳輸之間沒有對應關系。2.3 三種進度實現(xiàn)方案對比假進度、流計數與輪詢?yōu)榱俗屇氵x型時不用重新踩坑我把常見的三種做法做了個對比方案原理真實度適用場景缺點計時器假滾動Timer 每隔 100ms 給進度條 Value 加 1低演示 Demo、臨時工具和實際傳輸完全脫節(jié)失敗也照常滾字節(jié)流計數循環(huán)讀寫時累計實際字節(jié)數高生產環(huán)境、大文件、需要精確反饋必須手動拆讀和寫代碼稍多服務器輪詢上傳期間循環(huán)調 GetFileSize 探測中拿不到中間流的封裝 SDK多一次 RTT實時性差有額外開銷我只有在兩種情況下用輪詢一是上傳流程被第三方 SDK 封裝死了拿不到中間流二是斷點續(xù)傳時探測服務器已有字節(jié)數。平時的上傳工具字節(jié)流計數是毫無疑問的最優(yōu)解。選型最怕的是過度設計。如果只是內網傳幾十 KB 的小腳本文件假進度其實無傷大雅用戶不會盯著進度條。但只要文件可能超過 50MB或者要跨公網傳到別人的服務器就必須用流計數。這個場景下進度條承擔的不只是“好看”它還負責讓使用者判斷當前網絡狀態(tài)、決定要不要中斷重傳。一個假進度條在這種場景里就是誤導。還有關于憑據的一個小坑NetworkCredential 的 domain 參數對標準 FTP 沒有意義但在和 Active Directory 集成的 FTP 服務端比如 IIS FTP上用戶名要寫完整或者賬號信息字段不能為空。否則會收到 332 Need account for login 這類不常見的錯誤碼大多數人第一反應是查服務端權限實際上只是少填了賬號字段。3. 動手實現(xiàn)C# WinForm 的 FTP 上傳進度條完整代碼3.1 界面布局與后臺任務設計從觸發(fā)到收尾的完整鏈路界面只需要三個控件一個 ProgressBar 顯示進度一個 Label 顯示當前狀態(tài)一個 Button 觸發(fā)上傳。要支持取消就再加一個取消按鈕?？丶g的協(xié)作方式點擊上傳按鈕后不能直接在主線程里執(zhí)行上傳邏輯——網絡讀取的阻塞調用會讓整個窗體失去響應表現(xiàn)為白屏和拖動卡頓。正確做法是啟動 BackgroundWorker 把上傳邏輯丟到后臺線程UI 只通過事件接收進度并更新控件。這種做法跟前端里用 Web Worker 上傳大文件是一個思路耗時 IO 全部移出主線程主線程只負責渲染。WinForm 的 BackgroundWorker 就是這個角色的封裝它內部通過 SynchronizationContext 把進度事件封送到 UI 線程所以你在 ProgressChanged 里更新進度條不需要寫任何 Invoke 代碼。界面設計上要留意一個原則進度條控件本身只管顯示不要在里面塞業(yè)務邏輯。很多新手把文件大小計算、網速估算全塞進 ProgressChanged 回調結果 UI 線程被這些雜事拖住進度條反而卡頓。把上傳前就確定的值文件總長度提前存字段進度回調里只做兩件事——更新 Value、更新文案。3.2 核心上傳方法帶真實進度計的 FtpWebRequest 封裝下面的方法建議直接復制到公共類留出進度回調和取消檢查的接口WinForm、控制臺、Windows 服務都能復用// 帶真實進度回傳的FTP上傳方法 // onProgress: 已上傳字節(jié)數回調 // checkCancel: 返回true時終止上傳 public void UploadWithProgress( string localFilePath, string ftpUrl, string userName, string password, Actionlong onProgress, Funcbool checkCancel) { using (FileStream fs File.OpenRead(localFilePath)) { long fileLength fs.Length; FtpWebRequest request (FtpWebRequest)WebRequest.Create(ftpUrl); request.Method WebRequestMethods.Ftp.UploadFile; request.Credentials new NetworkCredential(userName, password); request.UseBinary true; // 二進制傳輸防止字節(jié)被改寫 request.UsePassive true; // 被動模式繞開防火墻限制 request.KeepAlive false; // 單一文件傳完即關閉連接 // 關鍵告訴服務器文件總長度否則無法判斷傳輸終態(tài) request.ContentLength fileLength; using (Stream requestStream request.GetRequestStream()) { byte[] buffer new byte[64 * 1024]; // 64KB緩沖區(qū) int bytesRead; long totalBytesWritten 0; while ((bytesRead fs.Read(buffer, 0, buffer.Length)) 0) { // 每次寫前檢查取消標記協(xié)作式取消 if (checkCancel ! null checkCancel()) { throw new OperationCanceledException(用戶取消上傳); } requestStream.Write(buffer, 0, bytesRead); totalBytesWritten bytesRead; // 上報真實字節(jié)數給UI層 onProgress?.Invoke(totalBytesWritten); } // 沖刷緩沖避免最后一小塊數據滯留本地 requestStream.Flush(); } // 必須拿到服務器確認響應才算真正完成 using (FtpWebResponse response (FtpWebResponse)request.GetResponse()) { if (response.StatusCode ! FtpStatusCode.ClosingData) { throw new Exception($服務器返回異常: {response.StatusCode}); } } } }四個容易忽略的配置這里一并說清。ContentLength 不設置或設錯服務器在數據通道關閉時可能用 451 之類的錯誤碼拒絕文件或者一直等數據直到超時。FtpWebRequest 依賴它判斷數據流的邊界所以務必從 FileStream.Length 取真實字節(jié)數。UseBinary 決定傳輸模式。對壓縮包、圖片、PDF 這類二進制文件如果誤用 ASCII 模式0x0A 單字節(jié)換行符會被改寫成 0x0D 0x0A 雙字節(jié)文件當場損壞。文本文件也建議直接用二進制模式服務器不做任何轉換兩邊字節(jié)完全一致。KeepAlivefalse 的意義在于單個文件傳完就斷開控制連接服務器端不會因為連接緩存讓文件句柄遲遲不釋放。循環(huán)傳多個文件時反過來KeepAlivetrue 能復用連接節(jié)省握手開銷。最后是 Flush。requestStream 內部有緩沖不 Flush 直接 Close某些實現(xiàn)會先關閉連接再倒緩存導致最后一批數據還沒到服務器就斷了。寫完循環(huán)后、關閉請求流前主動 Flush是避免“進度條 99% 卡住”的關鍵動作。3.3 跨線程更新進度條與狀態(tài)欄BackgroundWorker 的標準連接方式核心方法寫完接下來掛到 UI 上。這里用 BackgroundWorker 而不是 async/await是為了讓沒升級到 .NET 4.5 的舊工程也能直接抄// 點擊上傳按鈕后啟動后臺任務 private void btnUpload_Click(object sender, EventArgs e) { OpenFileDialog dlg new OpenFileDialog(); if (dlg.ShowDialog() ! DialogResult.OK) return; string localPath dlg.FileName; string uploadUrl ftp://192.168.1.100/share/ Path.GetFileName(localPath); long totalLength new FileInfo(localPath).Length; // 提前緩存避免回調里反復IO BackgroundWorker worker new BackgroundWorker(); worker.WorkerReportsProgress true; worker.WorkerSupportsCancellation true; // 后臺執(zhí)行上傳邏輯 worker.DoWork (s, e2) { try { UploadWithProgress( localPath, uploadUrl, ftpuser, ftppass, // 每次回調都報告百分比UserState傳出字節(jié)數 (bytes) { int percent (int)(bytes * 100 / totalLength); worker.ReportProgress(percent, bytes); }, // 取消檢查直接讀標志位 () worker.CancellationPending ); } catch (OperationCanceledException) { e2.Cancel true; // 用戶取消不按失敗處理 } catch (Exception ex) { e2.Result ex; // 異常帶回UI線程 } }; // 更新進度條與狀態(tài)欄 worker.ProgressChanged (s, e2) { progressBar.Value e2.ProgressPercentage; long bytes (long)e2.UserState; lblStatus.Text $已上傳 {FormatFileSize(bytes)} / {FormatFileSize(totalLength)}; }; // 上傳完成后的收尾 worker.RunWorkerCompleted (s, e2) { if (e2.Cancelled) { lblStatus.Text 已取消上傳; } else if (e2.Result is Exception ex) { lblStatus.Text 上傳失敗 ex.Message; } else { lblStatus.Text 上傳完成; } progressBar.Value 0; }; worker.RunWorkerAsync(); }進度更新這個環(huán)節(jié)最常報的錯是“跨線程操作無效”。DoWork 跑在后臺線程直接操作 progressBar 必然拋 InvalidOperationException。BackgroundWorker 的 ReportProgress 機制會自動封送到 UI 線程所以 ProgressChanged 里不需要任何 Invoke 代碼。這條規(guī)則不僅適用進度條狀態(tài)欄、列表控件都是同樣的處理方式。取消按鈕的配合也很簡單取消按鈕里調 worker.CancelAsync()然后立刻把取消按鈕禁用、上傳按鈕恢復防止重復點擊。CancelAsync 不會中斷正在執(zhí)行的代碼它只是把 CancellationPending 置為 true循環(huán)必須主動檢查這個標志才能退出。這就是協(xié)作式取消在 BackgroundWorker 里體現(xiàn)得最典型。3.4 關鍵參數清單按生產標準一次設對參數推薦值說明UseBinarytrue二進制傳輸防止換行符被改寫UsePassivetrue被動模式減少防火墻影響KeepAlivefalse單文件上傳后斷開控制連接ContentLength本地文件長度必須設置否則服務器無法確認文件邊界Timeout30000ms建立連接和發(fā)送命令的超時ReadWriteTimeout60000ms單個讀寫操作的最大耗時緩沖區(qū)64KB內存與網絡包數量的折中Timeout 和 ReadWriteTimeout 是兩回事這點很多人栽過。Timeout 管連接建立和命令收發(fā)ReadWriteTimeout 管數據流的單次讀寫。弱網下傳大文件默認 30 秒的 ReadWriteTimeout 可能不夠網絡抖動一下讀寫就中斷了。按文件大小和帶寬估算留出余量再設。另外把 FTP 當內部文件共享用跨網段比 SMB 省心是常見做法但一定要給共享目錄配專用賬號別用匿名登錄。匿名賬號在不少服務端被設置為只讀上傳時總是神秘失敗日志看不出來最后發(fā)現(xiàn)是權限位不對。4. 避坑與常見問題進度條翻車的五個真實場景4.1 現(xiàn)象進度卡在 99% 不動最后拋超時異常原因請求流內部的緩沖區(qū)沒有沖刷干凈數據還滯留在本地就關閉了連接服務器等不到最后一個數據塊超時斷開。解決關流之前顯式調用 requestStream.Flush()。同時檢查循環(huán)里是否把 Close 寫在了所有 Write 完成之前。我最初寫的版本就是 Write 完直接 Close導致最后一塊數據總是丟。從那以后我關閉任何網絡流的順序都固定為寫完 → Flush → Close一步不亂。4.2 現(xiàn)象進度條到 100%服務器上卻找不到文件原因最常見的有兩個。一是 UseBinary 沒設 true二進制文件被傳輸模式改寫字節(jié)服務端校驗失敗后丟棄二是請求流寫完就關沒等 GetResponse() 拿到 226 確認。解決使用二進制模式并保留到 GetResponse() 返回 226 才算真正結束。進度到 100% 只代表本地流寫完不等于服務器確認收完。如果你用第 3 章的封裝這段邏輯已經包含在內不要手動提前釋放 request。4.3 現(xiàn)象大文件一上傳界面就假死拖動窗口都費勁原因上傳邏輯跑在 UI 線程FtpWebRequest 同步方法讀取網絡流時阻塞線程窗口消息全部排隊界面自然無響應。解決把上傳丟到 BackgroundWorker 或 Task.Run 里。如果已經用了后臺線程但還是卡檢查 ProgressChanged 回調里有沒有耗時操作——有人習慣在回調里 new FileInfo(localPath).Length 重新取文件大小文件一大這步磁盤 IO 就能拖慢 UI。文件總長度應在點擊上傳時就緩存好回調里只做控件賦值。4.4 現(xiàn)象上傳中斷后服務器殘留半截文件下次繼續(xù)傳也不完整原因取消或斷網時服務端已經創(chuàng)建了目標文件并寫入了部分字節(jié)但因為沒收到結束標志文件被留在異常狀態(tài)。解決在取消和異常處理中主動發(fā) DELE 命令刪除殘留文件或者實現(xiàn)斷點續(xù)傳。第 5 章會給出 DELE 清理的完整代碼。這里先記住一個原則取消上傳不只是中斷本地循環(huán)還要向服務器聲明“我剛才那個文件不算數”否則你會在服務器上留一堆垃圾文件。4.5 現(xiàn)象返回 530 Authentication failed賬號密碼看著沒錯原因很多 FTP 服務器開了賬號鎖定策略密碼連續(xù)錯幾次會鎖一段時間或者服務端要求顯式 TLS。還有一種情況賬號是弱口令被安全掃描器探測并鎖定了你在客戶端這邊看賬號密碼完全沒問題。解決先登錄 FTP 服務端管理界面看賬號狀態(tài)再確認是否強制 FTPS。FtpWebRequest 里設置 EnableSsl true 即可走加密通道。生產環(huán)境一定單獨建低權限專用賬號別用 root 或管理員級別的賬號連應用順手把 FTP 弱口令這個隱患也堵上。5. 進階取消與斷點續(xù)傳——把進度條升級成可中斷任務5.1 協(xié)作式取消的完整閉環(huán)中斷循環(huán)、清理殘留、通知上層第 3 章用的 BackgroundWorker.CancellationPending 是標準的協(xié)作式取消。如果你的代碼要復用進 Windows Service 或命令行工具更通用的做法是注入 CancellationToken。無論哪種方式核心都在于“循環(huán)內部自己檢查標記、自己退出”。退出之后的清理動作往往被忽略。中斷上傳時服務器上已經生成了一個不完整的文件正確順序是先拋出 OperationCanceledException 退出循環(huán)然后在 catch 塊里發(fā)一條 DELE 命令刪除目標文件最后再重新拋出讓上層感知// 取消上傳時清理服務器殘留的半截文件 catch (OperationCanceledException) { try { FtpWebRequest delRequest (FtpWebRequest)WebRequest.Create(ftpUrl); delRequest.Method WebRequestMethods.Ftp.DeleteFile; delRequest.Credentials new NetworkCredential(userName, password); using (FtpWebResponse delResponse (FtpWebResponse)delRequest.GetResponse()) { // 刪除成功或返回550文件不存在都視為清理完成 } } catch { // 清理失敗不阻斷主流程 } throw; }DELE 命令走的是控制連接不涉及數據通道所以即使數據流已經中斷這條命令大概率還能成功。如果服務端本身有殘留文件自動清理策略這一步可以省略但作為應用層兜底做了永遠比不做好。這里的核心思想是取消操作要保證“不留臟數據”這比“快速退出”更重要。5.2 斷點續(xù)傳ContentOffset 與服務器已有文件大小的配合斷點續(xù)傳的底層是 FTP 的 REST 命令客戶端先發(fā)REST 1024再發(fā) STOR服務端就從第 1024 個字節(jié)開始繼續(xù)寫入。FtpWebRequest 里對應的是 ContentOffset 屬性設置后框架會自動在 STOR 前發(fā)送 REST 命令。實現(xiàn)分兩步。第一步探測服務器上已有的文件大小// 探測服務器已存在文件的大小用于斷點續(xù)傳 private long GetRemoteFileSize(string ftpUrl, string userName, string password) { FtpWebRequest req (FtpWebRequest)WebRequest.Create(ftpUrl); req.Method WebRequestMethods.Ftp.GetFileSize; req.Credentials new NetworkCredential(userName, password); req.UsePassive true; using (FtpWebResponse resp (FtpWebResponse)req.GetResponse()) { return resp.ContentLength; } }第二步把本地 FileStream 的位置跳到 offset同時設置 ContentOffset數據就從指定位置繼續(xù)// 斷點續(xù)傳從offset位置繼續(xù)上傳 long offset GetRemoteFileSize(ftpUrl, userName, password); using (FileStream fs File.OpenRead(localPath)) { fs.Seek(offset, SeekOrigin.Begin); // 本地從對應位置讀 FtpWebRequest request (FtpWebRequest)WebRequest.Create(ftpUrl); request.Method WebRequestMethods.Ftp.UploadFile; request.Credentials new NetworkCredential(userName, password); request.ContentOffset offset; // 服務器從對應位置寫 request.ContentLength fileLength - offset; // 剩余長度 // ...后續(xù)循環(huán)與第3章一致 }續(xù)傳場景最容易踩三個坑。第一ContentOffset 和 ContentLength 必須一起改。只設 offset 不把 ContentLength 改成剩余長度服務器會一直等數據直到超時。第二本地 FileStream 的 Seek 位置必須和 ContentOffset 嚴格一致一個傳的是 10MB 一個偏移卻是 0文件中間會有一段空洞或重復整個文件損壞。第三GetFileSize 對不存在的文件會拋 WebException很多服務端返回 550。所以首次上傳不能直接走續(xù)傳分支要捕獲異常后轉全量上傳。判斷服務器上是否存在文件除了 GetFileSize 拋異常還有更穩(wěn)妥的方式用 ListDirectory 列目錄看目標文件名是否在返回列表里。但這種方案會增加一次網絡往返對于工具類程序捕獲 550 異常已經是常見且夠用的做法。5.3 場景延伸FTP 監(jiān)控與定期同步的小工具把斷點續(xù)傳和進度條組合起來能做一個實用的 FTP 監(jiān)控與定期同步工具定時掃描本地目錄把新增文件全量上傳、把中斷的任務從斷點續(xù)傳同時把每批次的實時進度顯示到狀態(tài)欄。這個場景在數據采集終端、離線數據上報的運維環(huán)境里非常常見。一個容易忽略的細節(jié)斷點續(xù)傳只能解決“網絡中斷后重連續(xù)傳”的問題如果源文件在中途被其他進程修改了續(xù)傳會產生數據不一致。做定期同步之前必須確認文件處于穩(wěn)定狀態(tài)——最簡單的方法是兩次讀取文件大小間隔 200 毫秒兩次一致才進入上傳流程。這個“先確認再上傳”的習慣能避免大量臟數據進入服務器。6. 上傳后驗證比對大小、MD5 與列目錄確認文件真的完整進度條到 100% 只是本地視角服務器到底收了什么還得靠驗證。我習慣在上傳完成后強制走一遍三連驗證先比對大小、再列目錄看時間戳、最后抽檢 MD5。這一步看起來多花幾十毫秒但能攔住 90% 的“假成功”。大小比對最簡單用服務器 GetFileSize 返回的值對比本地文件長度。完全一致才能進下一步。這一步能攔住大部分字節(jié)被改寫、文件被截斷的場景。列目錄看時間戳適合確認“服務器上的文件確實是剛才那次上傳生成的”而不是某個舊的同名文件頂替了它。MD5 校驗最嚴謹但要做對。FTP 協(xié)議本身沒有標準的 MD5 校驗命令有些服務端實現(xiàn)了 XMD5、XSHA1 這類擴展命令但各家行為不一致。通用做法是把文件下載回來本地哈?；蛘咦尫掌鞫四_本算好 MD5 后再寫入一個同名的 .md5 文件兩邊各算各的// 本地計算文件MD5用于上傳后與服務器端比對 public string GetFileMd5(string filePath) { using (FileStream fs File.OpenRead(filePath)) using (var md5 System.Security.Cryptography.MD5.Create()) { byte[] hash md5.ComputeHash(fs); return BitConverter.ToString(hash).Replace(-, ).ToLowerInvariant(); } }對大文件算 MD5 有 IO 開銷所以我的習慣是分級驗證文件小于 100MB 直接算 MD5文件更大就只做大小比對加抽樣讀——取文件頭部、中部、尾部分別讀 1MB 算哈希三段一致基本能確認傳輸無損壞。這個“三段抽樣”的辦法在帶寬有限的場景里比全量 MD5 實用得多。驗證通過之后再更新界面狀態(tài)欄和日志文件。日志里要記錄文件路徑、服務器返回碼、傳輸耗時和驗證結果這些數據在你排查“為什么用戶總說傳了但服務器沒有”的時候是最直接的證據。做 FTP 工具這幾年我最大的教訓是永遠不相信進度條自己只相信校驗結果。從那以后我每次上傳完都強制走一遍大小比對大文件加抽檢這個習慣幫我攔下了無數次“看似成功實則損壞”的傳輸。這份資源的完整工程代碼里已經內置了這三步驗證邏輯直接跑起來就能看到效果。希望幫到你。本文還有配套的精品資源點擊獲取