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