簡介這份資料是一套基于VS2010與C# Winform的文件上傳示例面向需要把本地文件寫入局域網(wǎng)共享目錄的開發(fā)者也可用于企業(yè)內(nèi)部數(shù)據(jù)傳輸、共享盤上傳等場景。壓縮包共23個(gè)文件約36KB以6個(gè)cs源碼為核心配有sln解決方案與csproj項(xiàng)目配置并包含exe、pdb、resources/resx、settings等編譯調(diào)試與界面資源文件結(jié)構(gòu)適合直接打開對(duì)照學(xué)習(xí)。已有1429人學(xué)習(xí)。代碼圍繞文件選擇、UNC路徑與憑據(jù)連接、FileStream/NetworkStream讀寫、BackgroundWorker進(jìn)度反饋、異常處理和文件類型大小校驗(yàn)展開可幫助讀者理解從界面交互到網(wǎng)絡(luò)共享寫入的完整鏈路并據(jù)此排查權(quán)限不足、連接失敗等常見問題快速遷移到自己的上傳模塊中。1. 從「復(fù)制粘貼能用」到線上必翻車WinForm 上傳共享文件夾的真實(shí)邊界某個(gè)做設(shè)備巡檢的桌面項(xiàng)目客戶要求把每天生成的報(bào)表直接寫進(jìn)機(jī)房的共享文件夾理由很樸素那邊已經(jīng)有備份策略不想再維護(hù)額外的傳輸服務(wù)。聽起來File.Copy一行就能收工真上線第一周就翻車了開發(fā)機(jī)上跑得好好的裝到車間電腦上彈「拒絕訪問」換一臺(tái)機(jī)器又變成「找不到網(wǎng)絡(luò)路徑」還有一臺(tái)傳到 60% 卡死不動(dòng)。問題不在 C# 語法而在「文件上傳到共享文件夾」這件事本身牽扯三樣?xùn)|西SMB 會(huì)話、進(jìn)程身份、Windows 憑據(jù)緩存。WinForm 進(jìn)程默認(rèn)一樣都沒有。這篇記錄按「先看清鏈路 → 再寫上傳骨架 → 再解決憑據(jù) → 最后排坑」的順序走一遍代碼可以直接抄坑我盡量標(biāo)在你會(huì)踩的位置上。2. 拆開 SMB 上傳鏈路UNC 路徑、身份上下文與三種憑據(jù)方案2.1 一次寫\\server\share到底經(jīng)過了什么當(dāng)你寫下\\fileserver\share\report.xlsx這個(gè)路徑時(shí)Win32 的CreateFile并不會(huì)自己去連網(wǎng)絡(luò)它把活交給 mpr多重提供程序路由器重定向器重定向器再落到 SMB 客戶端驅(qū)動(dòng)上。整個(gè)過程拆開是四步解析主機(jī)名 → 建立到 445 端口的 TCP 連接 → 協(xié)商 SMB 版本并完成身份認(rèn)證得到一個(gè)會(huì)話Session→ 對(duì)這個(gè)共享做樹連接Tree Connect此后才是 CREATE / WRITE / CLOSE 這些文件級(jí)操作。真正決定成敗的是第三步。認(rèn)證用的憑據(jù)來自當(dāng)前進(jìn)程令牌域環(huán)境里走 Kerberos工作組或本地賬戶走 NTLM。關(guān)鍵在于整條鏈路上沒有任何一個(gè)參數(shù)能讓你「這次寫入用 A 賬號(hào)下次用 B 賬號(hào)」。憑據(jù)只在建會(huì)話時(shí)用一次之后緩存在內(nèi)核的會(huì)話表里按「服務(wù)器 用戶名」索引后續(xù)所有 IO 直接復(fù)用。這解釋了兩個(gè)最常見的困惑。第一為什么開發(fā)機(jī)上一切正?！阍谫Y源管理器里手輸過一次密碼會(huì)話已經(jīng)被建好了CtrlF5 調(diào)試的進(jìn)程正好蹭上了這個(gè)會(huì)話。第二為什么兩個(gè)不同賬號(hào)往同一臺(tái)服務(wù)器傳文件會(huì)報(bào) 1219因?yàn)閮?nèi)核發(fā)現(xiàn)「這臺(tái)服務(wù)器已經(jīng)有一條屬于別人的會(huì)話了」它拒絕在同一條會(huì)話上疊加第二套憑據(jù)。提示判斷當(dāng)前有沒有活著的會(huì)話用net use看列表或者Get-SmbConnection看客戶端側(cè)連接明細(xì)比猜快得多。2.2 三種身份方案先選型再寫代碼WinForm 上傳到共享文件夾本質(zhì)上是在回答「以誰的身份寫」這個(gè)問題只有三條路方案實(shí)現(xiàn)方式適用場景主要代價(jià)當(dāng)前登錄用戶不寫任何代碼直接寫 UNC 路徑域環(huán)境且登錄賬號(hào)已被授予共享寫權(quán)限換機(jī)器、換賬號(hào)就失效運(yùn)維無法自證顯式憑據(jù)建會(huì)話WNetAddConnection2mpr.dll工作組環(huán)境、NAS、客戶只給一個(gè)專用上傳賬號(hào)需要處理多重連接沖突與連接釋放登錄令牌模擬LogonUserWindowsIdentity.Impersonate一次進(jìn)程內(nèi)要訪問多臺(tái)不同憑據(jù)的服務(wù)器令牌生命周期管理更繞容易漏掉 Undo絕大多數(shù)現(xiàn)場我推薦第二條。原因是它足夠「局部」連接是進(jìn)程級(jí)的、可顯式釋放的出問題只影響這一臺(tái)上傳功能不會(huì)污染整個(gè)應(yīng)用的執(zhí)行上下文。第三條更適合「一臺(tái)客戶端要同時(shí)往三臺(tái)不同 NAS 寫」的極端場景如果只是往一臺(tái)文件服務(wù)器寫用WNetAddConnection2就夠別把簡單問題復(fù)雜化。有一個(gè)必須提前說清的邊界WNetAddConnection2建立的連接屬于當(dāng)前登錄會(huì)話不是屬于進(jìn)程。進(jìn)程退出連接可能還在反過來如果同會(huì)話里別的程序已經(jīng)用另一個(gè)賬號(hào)連過這臺(tái)服務(wù)器你這邊就會(huì)撞 1219。所以代碼里必須配對(duì)寫「建立」和「斷開」不能只建不斷。2.3 先用手把通道驗(yàn)證通再動(dòng) C#寫代碼之前先用 PowerShell 把「網(wǎng)絡(luò)通、認(rèn)證通、能寫」這三件事分開驗(yàn)證。這一步能省掉后面 80% 的瞎猜# 1) 只驗(yàn)端口不涉及任何憑據(jù)用來區(qū)分「網(wǎng)絡(luò)問題」和「權(quán)限問題」 Test-NetConnection -ComputerName fileserver -Port 445 # 2) 用目標(biāo)上傳賬號(hào)顯式建一次會(huì)話 # 用戶名格式三選一DOMAIN\user、fileserver\user本地賬戶、.\user net use \\fileserver\share /user:DOMAIN\uploader Pssw0rd # 3) 寫一個(gè)探針文件確認(rèn)共享目錄真的有寫權(quán)限不只是讀 Set-Content -Path \\fileserver\share\_probe.txt -Value ok -Encoding UTF8 # 4) 用完立刻刪掉避免它和你后面調(diào)試的憑據(jù)打架 net use \\fileserver\share /delete第 1 步失敗說明是網(wǎng)絡(luò)或防火墻445 被攔、主機(jī)名解析不到都會(huì)在這里暴露第 2 步失敗看返回碼1326 是賬號(hào)密碼不對(duì)1311 是找不到登錄服務(wù)器域控不可達(dá)第 3 步失敗但第 2 步成功說明賬號(hào)能連上但共享 ACL 或 NTFS 權(quán)限沒給寫這是純運(yùn)維問題代碼怎么寫都沒用。第 4 步經(jīng)常被跳過然后調(diào)試時(shí)莫名其妙報(bào) 1219。養(yǎng)成習(xí)慣手動(dòng)驗(yàn)證完就刪別留在會(huì)話表里。另外補(bǔ)一句關(guān)于映射盤不要用Z:\這種盤符。映射盤只在建立它的那個(gè)登錄會(huì)話內(nèi)可見服務(wù)、計(jì)劃任務(wù)、另一個(gè)用戶跑的進(jìn)程統(tǒng)統(tǒng)看不到。共享路徑永遠(yuǎn)寫 UNC。3. WinForm 端的上傳骨架選文件、跑后臺(tái)、報(bào)進(jìn)度3.1 界面線程和上傳線程的分工WinForm 里最容易犯的錯(cuò)不是上傳失敗而是上傳成功但窗口卡成白板。File.Copy和同步的FileStream.Write都是阻塞調(diào)用放在按鈕事件里UI 線程一堵進(jìn)度條不動(dòng)、取消按鈕點(diǎn)不動(dòng)用戶直接判定「程序死了」。正確寫法是把上傳整體丟進(jìn)Task.Run進(jìn)度用IProgressT回報(bào)。ProgressT在構(gòu)造時(shí)捕獲當(dāng)前的SynchronizationContextReport會(huì)自動(dòng)BeginInvoke回 UI 線程所以你在回調(diào)里直接改控件屬性是安全的不用手寫Invoke。private CancellationTokenSource _cts; private async void btnUpload_Click(object sender, EventArgs e) { if (openFileDialog1.ShowDialog() ! DialogResult.OK) return; _cts new CancellationTokenSource(); btnUpload.Enabled false; progressBar1.Value 0; // ProgressT 在 UI 線程構(gòu)造回調(diào)自動(dòng)回到 UI 線程 var progress new ProgressUploadProgress(p { progressBar1.Value (int)(p.Percent * 100); lblStatus.Text ${p.CurrentFile} {p.Sent / 1024 / 1024}MB / {p.Total / 1024 / 1024}MB; }); try { string uncDir \\fileserver\share\reports; await Task.Run(() FileUploader.UploadAsync( openFileDialog1.FileName, uncDir, progress, _cts.Token)); lblStatus.Text 上傳完成; } catch (OperationCanceledException) { lblStatus.Text 已取消; } catch (Exception ex) { // 不要只彈 ex.MessageWin32Exception 的 NativeErrorCode 才是關(guān)鍵 lblStatus.Text 上傳失敗 ex.Message; } finally { btnUpload.Enabled true; _cts.Dispose(); } }async void只允許出現(xiàn)在事件處理器上這是唯一合法場景await Task.Run把阻塞的 IO 移到線程池UI 線程立刻返回消息循環(huán)。finally里恢復(fù)按鈕狀態(tài)否則一次異常之后按鈕永遠(yuǎn)是灰的。3.2 流式復(fù)制別再用File.Copy一把梭File.Copy在局域網(wǎng)小文件上沒問題但它有三個(gè)硬傷沒有進(jìn)度、不能取消、失敗后目標(biāo)端留下半截文件。自己寫流式復(fù)制三個(gè)問題一起解決。public sealed class UploadProgress { public long Total { get; set; } public long Sent { get; set; } public string CurrentFile { get; set; } string.Empty; public double Percent Total 0 ? 0 : (double)Sent / Total; } public static async Task UploadAsync(string localPath, string uncDirectory, IProgressUploadProgress progress, CancellationToken token) { var fileName Path.GetFileName(localPath); var targetPath Path.Combine(uncDirectory, fileName); var tempPath targetPath .part; // 先寫臨時(shí)名成功后改名 const int BufferSize 1024 * 1024; // 1MBSMB2 下這個(gè)塊大小吞吐比較穩(wěn) var buffer new byte[BufferSize]; // 會(huì)進(jìn) LOH但只分配一次可接受 using (var source new FileStream(localPath, FileMode.Open, FileAccess.Read, FileShare.Read, BufferSize, FileOptions.SequentialScan)) using (var target new FileStream(tempPath, FileMode.Create, FileAccess.Write, FileShare.None, BufferSize, FileOptions.WriteThrough)) { long total source.Length, sent 0; int read; while ((read await source.ReadAsync(buffer, 0, buffer.Length, token)) 0) { token.ThrowIfCancellationRequested(); await target.WriteAsync(buffer, 0, read, token); sent read; progress?.Report(new UploadProgress { Total total, Sent sent, CurrentFile fileName }); } await target.FlushAsync(token); } // 同卷 Move 在 SMB 上是 rename 操作讀端不會(huì)看到半個(gè)文件 if (File.Exists(targetPath)) File.Delete(targetPath); File.Move(tempPath, targetPath); }參數(shù)逐個(gè)說。BufferSize取 1MB小于 64KB 時(shí)單次 WRITE 太小、往返次數(shù)多吞吐上不去大于 4MB 在千兆網(wǎng)卡上收益已經(jīng)不明顯反而放大單次失敗的重傳代價(jià)1MB 是常見的折中值。FileOptions.SequentialScan告訴系統(tǒng)這是順序讀它會(huì)提前預(yù)讀機(jī)械盤上提升明顯。FileShare.Read允許別人同時(shí)讀源文件避免「文件正被占用」目標(biāo)端用FileShare.None因?yàn)閭髁艘话氲奈募辉摫蝗魏稳舜蜷_。FileOptions.WriteThrough是關(guān)掉寫緩存直寫安全但慢。如果共享盤本身有 UPS、鏈路穩(wěn)定把它去掉吞吐會(huì)好一截如果是跨機(jī)房、鏈路抖保留它更穩(wěn)。這是取舍不是對(duì)錯(cuò)。最后兩行是「原子改名」代碼里用的是 .NET Framework 寫法因?yàn)镕ile.Move的 overwrite 重載要 .NET Core 3.0 才有。.NET 6 直接File.Move(tempPath, targetPath, true)。3.3 取消、超時(shí)與「看起來卡住」CancellationToken的檢查點(diǎn)要放在ReadAsync之后、WriteAsync之前。放在循環(huán)開頭也行但那樣用戶點(diǎn)了取消要等當(dāng)前這 1MB 寫完才響應(yīng)體感仍然卡。放中間是讓取消在「讀完一塊、還沒寫」的空隙生效最大延遲就是一次塊寫入的時(shí)間。超時(shí)不是CancellationToken能解決的。SMB 的 IO 沒有官方的 per-operation 超時(shí) API網(wǎng)絡(luò)斷了之后WriteAsync可能掛幾十秒才拋IOException。穩(wěn)妥做法是在外層再套一層Task.WhenAny(uploadTask, Task.Delay(TimeSpan.FromMinutes(10), token))超時(shí)了就取消并提示「網(wǎng)絡(luò)異常請(qǐng)重試」同時(shí)刪掉目標(biāo)端的.part文件。這個(gè)兜底邏輯不優(yōu)雅但比讓用戶對(duì)著卡死的進(jìn)度條干等強(qiáng)。另外進(jìn)度回調(diào)的頻率要控制。1MB 一塊一個(gè) 500MB 的文件就是 500 次Report每次都要BeginInvoke到 UI 線程消息隊(duì)列會(huì)被刷屏。常見做法是加個(gè)時(shí)間戳兩次回調(diào)間隔小于 100ms 就跳過只更新字節(jié)數(shù)不刷新界面。4. 帶憑據(jù)訪問WNetAddConnection2封裝與配置落地4.1 為什么net use能通、程序里卻拒絕訪問這是現(xiàn)場最高頻的誤解。運(yùn)維在服務(wù)器上net use測試通過就認(rèn)為「權(quán)限沒問題」結(jié)果客戶端一跑就報(bào)拒絕訪問。原因在于net use是在你的交互式登錄會(huì)話里建的連接而 WinForm 在客戶機(jī)上可能以另一個(gè)本地賬號(hào)運(yùn)行甚至以計(jì)劃任務(wù)的服務(wù)賬戶運(yùn)行那是完全獨(dú)立的登錄會(huì)話會(huì)話表是空的。同一個(gè)登錄會(huì)話內(nèi)的進(jìn)程共享內(nèi)核里的憑據(jù)緩存所以「我先在資源管理器里輸過密碼然后程序就能跑了」這種現(xiàn)象是真的但它不可交付?？蛻魮Q臺(tái)機(jī)器、換個(gè)賬號(hào)、重啟一次連接就沒了。結(jié)論很硬上傳功能自己負(fù)責(zé)建連接不能依賴任何外部預(yù)先建立的會(huì)話。4.2 P/Invoke 封裝與生命周期管理WNetAddConnection2在 mpr.dll 里簽名不復(fù)雜麻煩的是結(jié)構(gòu)體和標(biāo)志位。[StructLayout(LayoutKind.Sequential)] internal struct NETRESOURCE { public int dwScope; public int dwType; // 1 RESOURCETYPE_DISK public int dwDisplayType; public int dwUsage; public string lpLocalName; // 留 null 表示不做盤符映射 public string lpRemoteName; // \\fileserver\share public string lpComment; public string lpProvider; } internal static class NativeNet { [DllImport(mpr.dll, CharSet CharSet.Unicode)] public static extern int WNetAddConnection2(ref NETRESOURCE nr, string password, string username, int flags); [DllImport(mpr.dll, CharSet CharSet.Unicode)] public static extern int WNetCancelConnection2(string name, int flags, bool force); } public sealed class NetworkShare : IDisposable { private const int RESOURCETYPE_DISK 1; private const int CONNECT_TEMPORARY 0x00000004; private readonly string _remote; private bool _connected; public NetworkShare(string uncPath, string userName, string password) { _remote uncPath.TrimEnd(\\); var nr new NETRESOURCE { dwType RESOURCETYPE_DISK, lpRemoteName _remote, lpLocalName null }; int rc NativeNet.WNetAddConnection2(ref nr, password, userName, CONNECT_TEMPORARY); if (rc ! 0) { // 1219 單獨(dú)提示運(yùn)維一看就懂 string hint rc 1219 ? 該服務(wù)器已有其他賬號(hào)的連接請(qǐng)先斷開或重啟客戶端 : 連接共享失敗; throw new IOException(${hint}錯(cuò)誤碼 {rc}); } _connected true; } public void Dispose() { if (!_connected) return; NativeNet.WNetCancelConnection2(_remote, 0, true); _connected false; } }幾個(gè)參數(shù)值得單獨(dú)講。dwType 1是磁盤資源寫錯(cuò)成 0 會(huì)返回 87參數(shù)錯(cuò)誤。lpLocalName null表示不映射盤符——一旦映射了盤符這個(gè)盤符只對(duì)當(dāng)前登錄會(huì)話有效其他進(jìn)程照樣看不到反而增加清理負(fù)擔(dān)。flags用CONNECT_TEMPORARY0x4而不是 00 表示持久連接會(huì)在用戶配置文件里留下重連記錄客戶機(jī)重啟后自動(dòng)重連憑據(jù)過期了就是一個(gè)莫名其妙的失敗源。臨時(shí)連接在會(huì)話結(jié)束或進(jìn)程退出時(shí)自動(dòng)清理更干凈。Dispose里用force true是為了在還有句柄打開的情況下也能斷開代價(jià)是可能中斷別人的操作。如果上傳是在獨(dú)立進(jìn)程里跑安全如果是共享進(jìn)程謹(jǐn)慎。我一般在上傳方法的finally里釋放不給它泄漏的機(jī)會(huì)。userName的三種格式必須區(qū)分清楚DOMAIN\user走域認(rèn)證fileserver\user走那臺(tái)機(jī)器上的本地賬戶.\user走本機(jī)賬戶。寫錯(cuò)了不會(huì)報(bào)「格式錯(cuò)誤」只會(huì)返回 1326讓你誤以為密碼打錯(cuò)了。4.3 把憑據(jù)放進(jìn)配置DPAPI 加密與啟動(dòng)預(yù)檢明文密碼寫在app.config里是能過編譯、過不了驗(yàn)收的寫法。常見做法是用 DPAPI 的ProtectedData作用域選CurrentUser——同一臺(tái)機(jī)器上換個(gè)賬號(hào)都解不開比明文強(qiáng)得多。// 寫入安裝或首次配置時(shí)執(zhí)行一次 var cipher ProtectedData.Protect( Encoding.UTF8.GetBytes(txtPassword.Text), null, DataProtectionScope.CurrentUser); File.WriteAllText(C:\ProgramData\App\upload.dat, Convert.ToBase64String(cipher)); // 讀取 var raw Convert.FromBase64String(File.ReadAllText(C:\ProgramData\App\upload.dat)); var password Encoding.UTF8.GetString( ProtectedData.Protect(raw, null, DataProtectionScope.CurrentUser) is var _ ? raw : raw);上面讀取那段是我故意寫殘的示意正確的是ProtectedData.Unprotect(raw, null, DataProtectionScope.CurrentUser)。參數(shù)里的null是可選熵值加上它可以讓別的程序即使同賬號(hào)也解不開一般填一個(gè)固定的字節(jié)數(shù)組常量。配置項(xiàng)至少要有四個(gè)RemoteRootUNC 根、UserName、加密后的密碼文件路徑、ProbeOnStartup。然后做一個(gè)啟動(dòng)預(yù)檢應(yīng)用啟動(dòng)時(shí)在后臺(tái)線程建一次連接、寫一個(gè)_probe_機(jī)器名.tmp文件、刪掉、斷開。失敗就把主界面上的上傳按鈕置灰并給出錯(cuò)誤碼。這個(gè)動(dòng)作 200 毫秒但能把「用戶點(diǎn)了上傳才報(bào)錯(cuò)」變成「一進(jìn)來就知道環(huán)境不通」省掉大量溝通成本。5. 避坑清單上線后最容易撞的六類現(xiàn)場5.1 拒絕訪問、多重連接與「目錄不存在」的假象現(xiàn)象一Directory.Exists(\\fileserver\share\reports)返回 false但目錄明明存在。原因很反直覺當(dāng)進(jìn)程對(duì)共享沒有訪問權(quán)限時(shí)Directory.Exists不會(huì)拋異常它直接返回 false把「沒權(quán)限」和「不存在」糊成一個(gè)結(jié)果。你按「目錄不存在」去建目錄再收到一個(gè)拒絕訪問就徹底糊涂了。解決方式是永遠(yuǎn)不要用Directory.Exists做權(quán)限判斷改成顯式嘗試寫探針文件把UnauthorizedAccessException單獨(dú)捕獲并提示「共享無寫權(quán)限」。現(xiàn)象二報(bào) 1219提示「不允許一個(gè)用戶使用一個(gè)以上用戶名與一個(gè)服務(wù)器或共享資源的多重連接」。原因是當(dāng)前登錄會(huì)話里已經(jīng)有一條到這臺(tái)服務(wù)器的會(huì)話屬于另一個(gè)賬號(hào)。常見觸發(fā)順序是運(yùn)維先用管理員賬號(hào)net use測過沒刪你的程序再用上傳賬號(hào)連。解決辦法有兩條一是上線前無條件執(zhí)行一次WNetCancelConnection2清場注意可能影響同會(huì)話的其他程序二是承認(rèn)這個(gè)限制、在錯(cuò)誤提示里直接告訴用戶「請(qǐng)重啟客戶端或斷開已有連接」。我的選擇是先清場再連失敗再給提示?，F(xiàn)象三錯(cuò)誤碼 1326 與 86 混著出現(xiàn)。1326 是「登錄失敗用戶名或密碼不正確」86 是「指定的網(wǎng)絡(luò)密碼不正確」。兩個(gè)都指向憑據(jù)但前者多半是用戶名格式寫錯(cuò)少寫了DOMAIN\后者多半是密碼里含有特殊字符在配置文件里被轉(zhuǎn)義吃掉了。密碼里帶、、%時(shí)建議直接改用文件存 DPAPI 密文不要走 XML 屬性。5.2 大文件中斷、超時(shí)與共享盤「休眠」現(xiàn)象四小文件正常超過 500MB 的文件傳到一半報(bào) 64「指定的網(wǎng)絡(luò)名不再可用」重試又好了。這通常不是代碼問題。一是網(wǎng)絡(luò)設(shè)備或防火墻對(duì)長連接有會(huì)話老化時(shí)間空閑幾十秒就掐二是目標(biāo)端是做了休眠策略的 NAS磁盤休眠喚醒期間 IO 掛起客戶端等不及就斷了。解決上分兩層應(yīng)用層做重試捕獲IOException后最多重試 3 次每次間隔遞增2s、4s、8s并且從斷點(diǎn)續(xù)傳而不是從頭傳否則 1GB 文件重試三次等于傳三遍環(huán)境層推動(dòng)運(yùn)維把共享端休眠關(guān)掉或者把心跳包間隔壓到小于老化時(shí)間。現(xiàn)象五進(jìn)度條走到 100%但文件大小是 0 或者不完整。這是沒做 flush 就關(guān)流的典型癥狀。FileStream的Close/Dispose通常會(huì) flush但如果用了BufferedStream且外層提前異常緩沖區(qū)里的數(shù)據(jù)就丟了。解決就是顯式await target.FlushAsync(token)再進(jìn)using的釋放流程順序不能反。同時(shí)保留.part后綴讓任何人都能一眼看出這是半成品。5.3 文件名、長路徑與臨時(shí)占用現(xiàn)象六路徑總長超過 260 字符就拋PathTooLongException或者中文文件名在共享端變成亂碼。長度問題在 .NET Framework 上尤其頑固光加\\?\UNC\前綴不夠還要在app.config里開長路徑開關(guān)并且在應(yīng)用清單里聲明longPathAware三件事缺一不可configuration runtime AppContextSwitchOverrides valueSwitch.System.IO.UseLegacyPathHandlingfalse;Switch.System.IO.BlockLongPathsfalse / /runtime /configuration亂碼則基本不是編碼問題而是文件名里帶了 Windows 不允許的字符\ / : * ? |或者尾部是空格、點(diǎn)號(hào)這類名字在本地能建寫到 SMB 上被規(guī)范化后就成了另一個(gè)名字。上傳前統(tǒng)一做一次文件名清洗并且顯式拒絕CON、PRN、AUX、NUL這些保留名——它們即便加了擴(kuò)展名在部分共享端仍然建不出來。還有一類不在代碼里目標(biāo)端的殺毒軟件或同步客戶端會(huì)短暫鎖住剛寫完的文件導(dǎo)致File.Move拋IOException「文件正被另一進(jìn)程使用」。解決辦法是給改名動(dòng)作加一個(gè)小重試3 次每次 200ms比一失敗就報(bào)錯(cuò)體面得多。6. 進(jìn)階把「傳過去」變成可驗(yàn)證的上傳6.1 邊寫邊算哈希落地后再核一次文件「傳過去了」和「傳對(duì)了」是兩件事。千兆內(nèi)網(wǎng)也有靜默損壞的概率跨公網(wǎng)鏈路更高。穩(wěn)妥做法是在寫入的同時(shí)用CryptoStream或增量HashAlgorithm算一遍 SHA256傳完再從共享端讀回來算一遍對(duì)比。注意讀回校驗(yàn)會(huì)把 IO 翻倍大文件建議只在前 N 次上傳或抽樣時(shí)做。// 寫的同時(shí)算哈希避免二次讀源文件 using var sha SHA256.Create(); using var crypto new CryptoStream(Stream.Null, sha, CryptoStreamMode.Write); int read; while ((read await source.ReadAsync(buffer, 0, buffer.Length, token)) 0) { await target.WriteAsync(buffer, 0, read, token); crypto.Write(buffer, 0, read); // 同一份字節(jié)喂給哈希 sent read; } crypto.FlushFinalBlock(); string localHash Convert.ToHexString(sha.Hash); // .NET Framework 用 BitConverter.ToStringCryptoStream掛到Stream.Null上是刻意的它只負(fù)責(zé)吞字節(jié)算摘要不落盤、不額外占空間。FlushFinalBlock必須調(diào)用否則最后一塊不進(jìn)哈希算出來的值永遠(yuǎn)對(duì)不上——這個(gè)坑我踩過一次查了兩個(gè)小時(shí)才發(fā)現(xiàn)是少了一行。6.2 一個(gè)能自證的日志格式上傳失敗最難查的是「到底卡在哪一步」。日志里至少要有五個(gè)字段時(shí)間、源文件全路徑、目標(biāo) UNC 全路徑、當(dāng)前階段連接 / 寫入 / 改名 / 校驗(yàn)、錯(cuò)誤碼。階段字段是關(guān)鍵它把「拒絕訪問」定位到「連接階段」還是「改名階段」指向的排查方向完全不同。階段典型錯(cuò)誤碼該找誰連接53 / 64 / 67 / 1219 / 1326網(wǎng)絡(luò)或賬號(hào)運(yùn)維寫入5 / 39 / 112共享 ACL、磁盤滿改名32 / 5目標(biāo)端占用、權(quán)限繼承校驗(yàn)無錯(cuò)誤碼哈希不一致鏈路質(zhì)量、中間設(shè)備6.3 上線前我會(huì)強(qiáng)制跑的三條檢查第一條斷網(wǎng)重連。上傳到一半拔網(wǎng)線確認(rèn)程序在 10 分鐘內(nèi)給出明確失敗提示.part文件被清理且重試能從頭再來不報(bào) 1219。第二條換賬號(hào)跑。用另一個(gè)本地賬號(hào)登錄同一臺(tái)機(jī)器跑一遍上傳驗(yàn)證程序不依賴當(dāng)前用戶的任何會(huì)話緩存。第三條滿盤與只讀。把共享目錄臨時(shí)設(shè)成只讀確認(rèn)提示是「無寫權(quán)限」而不是「目錄不存在」。這三條每次發(fā)版前跑一遍五分鐘能擋掉絕大多數(shù)的現(xiàn)場工單。從那以后我每次交付這類上傳功能都會(huì)在啟動(dòng)時(shí)強(qiáng)制走一遍「建連 → 寫探針 → 刪探針 → 斷開」的預(yù)檢寧可讓用戶一進(jìn)來就看到紅字也不讓他在點(diǎn)了上傳之后對(duì)著進(jìn)度條猜。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取