做 .NET 桌面客戶端開發(fā)的同學(xué)基本都會(huì)撞上同一個(gè)問題程序分發(fā)出去之后怎么讓用戶手上的版本始終保持最新。裝機(jī)量少還好說手動(dòng)下載安裝包也能撐一陣子一旦用戶規(guī)模上來自動(dòng)更新就不是“要不要做”而是“什么時(shí)候做”了。這篇分享我圍繞 .NET 桌面應(yīng)用自動(dòng)更新這個(gè)主題把常見的幾種更新方案從頭到尾捋一遍重點(diǎn)講清楚云端更新怎么落地適合正在選型或者準(zhǔn)備改造現(xiàn)有更新機(jī)制的人參考。先說結(jié)論市面上沒有一套方案能通吃所有場景。你的應(yīng)用是單文件工具還是大型業(yè)務(wù)系統(tǒng)目標(biāo)用戶是內(nèi)網(wǎng)還是公網(wǎng)團(tuán)隊(duì)有沒有服務(wù)端運(yùn)維能力這些都會(huì)直接影響方案選擇。我整理出五種主流做法分別說明原理、優(yōu)缺點(diǎn)和適用場景再挑一條最實(shí)用的云端更新路徑把服務(wù)端和客戶端的實(shí)現(xiàn)細(xì)節(jié)完整走一遍。最后會(huì)列出我實(shí)際踩過的坑以及對(duì)應(yīng)的排查思路這部分不看真的會(huì)吃虧。1. 更新方案選型先想清楚這四件事再動(dòng)手1.1 為什么自動(dòng)更新這么重要很多團(tuán)隊(duì)把自動(dòng)更新當(dāng)成“錦上添花”等到線上出問題才后悔。我見過一個(gè)內(nèi)部工具因?yàn)槟硞€(gè)業(yè)務(wù)邏輯寫錯(cuò)修復(fù)后只能靠運(yùn)維手動(dòng)去每臺(tái)機(jī)器上替換文件一百多臺(tái)機(jī)器折騰了一整天。這不是段子是真實(shí)發(fā)生過的事。自動(dòng)更新解決的不僅是“換版本”這個(gè)動(dòng)作它本質(zhì)上是在降低版本迭代的邊際成本。沒有更新機(jī)制時(shí)每次發(fā)版都是一次高風(fēng)險(xiǎn)的運(yùn)維事件有了可靠的更新鏈路發(fā)版就變成一件可以隨時(shí)觸發(fā)、批量完成、無感生效的常規(guī)操作。對(duì)做 .NET 桌面程序的人來說這帶來的直接好處是Bug 修復(fù)更快觸達(dá)用戶業(yè)務(wù)需求迭代不再受安裝包分發(fā)方式牽制同時(shí)還能通過更新日志掌握用戶實(shí)際運(yùn)行的版本分布。但自動(dòng)更新也會(huì)引入新的復(fù)雜度。更新包怎么做版本校驗(yàn)、怎么處理文件占用、怎么防止更新一半失敗導(dǎo)致程序不可用、怎么避免被安全軟件攔截這些不在前期設(shè)計(jì)階段想明白上線后就是連環(huán)坑。1.2 五大自動(dòng)更新方案全景對(duì)比為了把問題說透我把常見的更新方案歸納為五類傳統(tǒng)安裝包派發(fā)、ClickOnce 發(fā)布、自建更新器配合文件服務(wù)、開源更新組件集成、云托管自動(dòng)更新服務(wù)。下面這張表把關(guān)鍵差異列出來了。方案實(shí)現(xiàn)復(fù)雜度用戶體驗(yàn)適用場景主要限制傳統(tǒng)安裝包派發(fā)低差需手動(dòng)下載小規(guī)模內(nèi)部工具無法覆蓋大規(guī)模用戶ClickOnce中中啟動(dòng)時(shí)檢查VSTO 插件、輕量工具配置繁瑣、證書問題多自建更新器 文件服務(wù)高好可精細(xì)控制中大型業(yè)務(wù)系統(tǒng)需要自行處理異常邏輯開源更新組件中好常規(guī)桌面應(yīng)用受開源項(xiàng)目維護(hù)狀態(tài)影響云托管自動(dòng)更新服務(wù)低好開箱即用公網(wǎng)分發(fā)的普通應(yīng)用受特定平臺(tái)約束需評(píng)估成本這五類不是互斥關(guān)系。我見過不少項(xiàng)目是“自建更新器 對(duì)象存儲(chǔ) CDN”的組合其實(shí)是第三類和第五類的混合體這也是我比較推薦的一種落地方式。1.3 方案選型的核心判斷標(biāo)準(zhǔn)選擇更新方案時(shí)我建議按四個(gè)維度打分評(píng)估。第一是網(wǎng)絡(luò)環(huán)境。目標(biāo)用戶全部在內(nèi)網(wǎng)還是分布在公網(wǎng)內(nèi)網(wǎng)環(huán)境可以不考慮 CDN 加速但要注意文件服務(wù)器的帶寬和并發(fā)公網(wǎng)環(huán)境必須考慮下載速度和斷點(diǎn)續(xù)傳。第二是文件規(guī)模和更新頻率。如果每次更新都是一兩百兆的大包增量更新的優(yōu)先級(jí)就要調(diào)高如果只是配置文件微調(diào)全量更新反而更省事。第三是回滾能力。你能否接受用戶更新到新版本后出問題然后無法快速回到舊版本回滾機(jī)制的復(fù)雜度直接影響整體設(shè)計(jì)很多更新方案在這一點(diǎn)上差別很大。第四是團(tuán)隊(duì)維護(hù)成本。自建方案靈活但需要長期維護(hù)更新服務(wù)現(xiàn)成組件省事但要接受它的行為邊界。我見過有人把某個(gè)開源更新組件用完就擱置結(jié)果被 .NET 版本兼容性問題卡了半年這類風(fēng)險(xiǎn)要提前評(píng)估。把這四個(gè)維度想清楚方案基本能定下來。下面把每個(gè)方案的內(nèi)部機(jī)制拆開看。2. 核心細(xì)節(jié)拆解版本管理、增量更新與更新包安全2.1 版本號(hào)管理與更新清單設(shè)計(jì)不管哪種方案底層都離不開“更新清單”這個(gè)東西。它的作用很簡單告訴客戶端當(dāng)前有哪些新版本、去哪里下載、怎么校驗(yàn)。很多自動(dòng)更新翻車都是因?yàn)楦虑鍐卧O(shè)計(jì)得太隨意。更新清單至少需要包含五個(gè)關(guān)鍵字段應(yīng)用名稱或應(yīng)用 ID、當(dāng)前的版本號(hào)、更新包的版本號(hào)、下載地址、包哈希值。還有兩個(gè)容易被忽略的字段最低兼容版本和更新說明。最低兼容版本用來處理“用戶版本太老不能直接跳到最新版”的情況更新說明可以展示給用戶決定是否立即更新。版本號(hào)建議遵循語義化版本規(guī)則形如1.2.3分別對(duì)應(yīng)主版本、次版本、補(bǔ)丁版本。檢查更新的核心邏輯就是比較版本號(hào)大小而不是簡單判斷字符串是否相等。用 C# 自帶的Version類型就能完成這個(gè)比較但要注意Version.TryParse對(duì)格式很敏感版本號(hào)里不要混入日期、構(gòu)建號(hào)以外的非數(shù)字字段否則解析階段就會(huì)埋雷。我曾經(jīng)維護(hù)過一個(gè)內(nèi)部工具最初更新清單只放在 HTTP 根目錄下既沒有簽名也沒有哈希校驗(yàn)結(jié)果某個(gè)用戶裝了一個(gè)被篡改的清單文件應(yīng)用順著清單下載到了錯(cuò)誤文件整個(gè)機(jī)器上的程序直接起不來。排查到最后才發(fā)現(xiàn)問題出在“信任了不該信任的響應(yīng)”。從那以后只要條件允許更新清單一律走 HTTPS并且對(duì)清單內(nèi)容做簽名校驗(yàn)。2.2 全量更新與增量更新的取舍全量更新就是讓用戶下載一個(gè)完整的安裝包或壓縮包。優(yōu)點(diǎn)是邏輯簡單不容易出錯(cuò)缺點(diǎn)是每次更新都要傳輸全部文件體積大、耗時(shí)長。增量更新則是只下載有變化的部分。常見做法有兩種一種是文件級(jí)別的增量即比較新舊版本的文件清單只下載新增或變化的文件另一種是更細(xì)粒度的二進(jìn)制差異更新通過對(duì)比新舊版本二進(jìn)制內(nèi)容生成差異包能進(jìn)一步縮小體積。后者在 .NET 桌面應(yīng)用里不算常見因?yàn)槌绦蚣瘍?nèi)部結(jié)構(gòu)稍有變化差異包可能覆蓋大片區(qū)域收益未必明顯。對(duì)于大多數(shù)應(yīng)用文件級(jí)別的增量已經(jīng)夠用。增量更新的核心難點(diǎn)是客戶端必須知道“我從現(xiàn)在的版本升級(jí)到目標(biāo)版本需要哪些文件”。這要求服務(wù)端能生成任意兩個(gè)版本之間的差量文件列表。實(shí)際工程里不會(huì)為每一對(duì)版本都生成差量而是做線性增量只支持從上一版本升級(jí)到當(dāng)前版本跳版本時(shí)強(qiáng)制全量更新。這個(gè)限制能省掉大量存儲(chǔ)空間和生成算力也避免增量鏈路復(fù)雜化引入新 Bug。還需要考慮增量更新不是只能省流量它對(duì)弱網(wǎng)環(huán)境的成功率也有幫助。體積小了傳輸中斷的概率和重試成本都會(huì)降低。但千萬不要把增量包做得過于瑣碎比如每個(gè)文件都比一比生成一個(gè)獨(dú)立小包這樣請(qǐng)求次數(shù)過多反而會(huì)拖慢整體速度。比較合理的做法是將變更文件打成一個(gè) zip 壓縮包客戶端下載后解壓再按清單逐個(gè)替換。2.3 更新包的簽名與完整性校驗(yàn)很多人忽視更新包簽名覺得 HTTPS 已經(jīng)足夠安全。實(shí)際上更新服務(wù)被攻擊、文件被替換到惡意版本這類風(fēng)險(xiǎn)是客觀存在的。更新包在傳輸過程中即使走了 HTTPS也存在被服務(wù)端惡意篡改的極端情況。對(duì)桌面客戶端來說校驗(yàn)更新包的哈希值是最基本的底線。哈希校驗(yàn)的操作過程并不復(fù)雜。發(fā)布更新時(shí)計(jì)算出每個(gè)包 SHA256 值寫進(jìn)更新清單客戶端下載完畢后先算本地文件的 SHA256和清單里的值比對(duì)一致才允許替換。這樣能防止文件在傳輸過程中損壞也能防止中間人篡改。但哈希校驗(yàn)有個(gè)盲區(qū)更新清單本身如果是偽造的里面的哈希值也是偽造的。所以嚴(yán)謹(jǐn)?shù)淖龇ㄊ菍?duì)更新清單做數(shù)字簽名或者把哈希值放在簽名過的 JSON 結(jié)構(gòu)里?？蛻舳藘?nèi)置公鑰驗(yàn)證簽名通過后再信任清單內(nèi)容。實(shí)操中簽名環(huán)節(jié)很容易因?yàn)樽C書有效期問題翻車。代碼簽名證書通常按年購買一旦過期后續(xù)版本就沒法簽名客戶端的強(qiáng)校驗(yàn)會(huì)把新版本當(dāng)成非法包直接攔掉。在發(fā)布流水線里加入證書到期提醒是我給自己記下的重要經(jīng)驗(yàn)。2.4 回滾與失敗恢復(fù)機(jī)制自動(dòng)更新最怕的過程是更新到一半程序退出然后既沒更新成功舊版本也跑不了了。為了應(yīng)對(duì)這種場景必須在設(shè)計(jì)階段預(yù)留回滾通道。常見的做法是雙目錄或文件備份。在更新前把當(dāng)前運(yùn)行的關(guān)鍵文件復(fù)制到一個(gè)備份目錄更新完成后先啟動(dòng)新版本做冒煙測試如果啟動(dòng)失敗自動(dòng)從備份目錄恢復(fù)舊文件。對(duì)于 .NET 桌面應(yīng)用可以直接利用目錄切換的技巧主程序啟動(dòng)時(shí)讀取“當(dāng)前運(yùn)行版本”指針更新器負(fù)責(zé)切換指針。這種思路能最大程度保證主目錄文件的原子性。還有一類更新失敗不是文件被替換壞而是新版本本身有嚴(yán)重 Bug用戶升級(jí)后無法正常工作。此時(shí)僅僅回滾文件還不行需要服務(wù)端提供“緊急停發(fā)”能力。做法是在更新清單里增加一個(gè)force_rollback_version字段當(dāng)線上發(fā)現(xiàn)嚴(yán)重問題時(shí)把這個(gè)字段指向已知可用版本客戶端檢查清單后發(fā)現(xiàn)當(dāng)前版本被強(qiáng)制回滾就直接拉取舊版本覆蓋回來?；貪L邏輯需要在客戶端時(shí)刻保持“舊版本信息可用”的狀態(tài)。如果更新器把舊版本信息放在注冊(cè)表里重裝系統(tǒng)后注冊(cè)表會(huì)丟失應(yīng)用將失去回滾依據(jù)因此關(guān)鍵狀態(tài)信息應(yīng)同時(shí)寫入應(yīng)用數(shù)據(jù)目錄和注冊(cè)表互為冗余。3. 實(shí)操落地寫一個(gè)能上線的云更新客戶端3.1 更新服務(wù)端的文件組織方式自建更新服務(wù)時(shí)我最推薦的文件組織方式是把更新內(nèi)容放在對(duì)象存儲(chǔ)上前面接一層 CDN 加速。使用對(duì)象存儲(chǔ)能解決存儲(chǔ)容量、帶寬峰值和跨地域訪問的問題同時(shí)還能方便地設(shè)置訪問權(quán)限和生命周期規(guī)則。另一個(gè)明顯的優(yōu)勢是對(duì)象存儲(chǔ)自帶版本管理和靜態(tài)網(wǎng)站托管能力更新清單可以當(dāng)作一個(gè)靜態(tài) JSON 文件維護(hù)。文件目錄的設(shè)計(jì)我習(xí)慣用這樣的結(jié)構(gòu)https://update.example.com/ ├── manifest.json ├── release/ │ ├── 1.0.0/ │ │ ├── app.zip │ │ └── checksum.sha256 │ └── 1.1.0/ │ ├── app.zip │ └── checksum.sha256 └── delta/ └── 1.0.0_to_1.1.0/ └── delta.zipmanifest.json里存放當(dāng)前發(fā)布的最新版本和下載地址。每個(gè)版本目錄獨(dú)立便于做版本回溯和歷史發(fā)布記錄。之所以在版本目錄里保留checksum.sha256是為了讓客戶端可以單獨(dú)下載該文件進(jìn)行校驗(yàn)不用依賴清單里的哈希值。當(dāng)然把哈希直接放進(jìn)清單也可以二選一即可。對(duì)象存儲(chǔ)的路徑規(guī)劃需要謹(jǐn)慎因?yàn)槁窂阶兏馕吨蛻舳司彺媸?。我見過有團(tuán)隊(duì)把版本號(hào)放在域名里每次發(fā)版都換子域名結(jié)果客戶端硬編碼的更新地址全部失效導(dǎo)致老用戶無法拉取更新。域名盡量保持穩(wěn)定版本信息放在路徑或查詢參數(shù)里這個(gè)設(shè)計(jì)原則在更新系統(tǒng)里同樣適用。3.2 客戶端更新檢查與下載實(shí)現(xiàn)客戶端的更新檢查流程本質(zhì)上是一個(gè)“讀取遠(yuǎn)端狀態(tài)、比對(duì)本地狀態(tài)、執(zhí)行拉取動(dòng)作”的狀態(tài)機(jī)。下面給出一個(gè)精簡版的核心邏輯代碼中注釋部分說明每個(gè)環(huán)節(jié)的意圖。public class UpdateChecker { private readonly string _manifestUrl; private readonly string _localVersion; public UpdateChecker(string manifestUrl, string localVersion) { _manifestUrl manifestUrl; _localVersion localVersion; } public async TaskUpdateInfo CheckAsync(CancellationToken ct) { using var client new HttpClient(); client.Timeout TimeSpan.FromSeconds(15); // 拉取更新清單這一步務(wù)必走 HTTPS避免明文傳輸被篡改 var json await client.GetStringAsync(_manifestUrl, ct); var manifest JsonSerializer.DeserializeUpdateManifest(json); if (manifest null) throw new InvalidDataException(更新清單解析失敗); var local Version.Parse(_localVersion); var remote Version.Parse(manifest.LatestVersion); // 本地版本已經(jīng)是最新直接返回空狀態(tài) if (remote local) return UpdateInfo.NotAvailable(); return new UpdateInfo { LatestVersion manifest.LatestVersion, DownloadUrl manifest.DownloadUrl, Sha256 manifest.Sha256, ReleaseNotes manifest.ReleaseNotes }; } }檢查更新時(shí)要注意兩個(gè)性能問題。第一是超時(shí)時(shí)間不能設(shè)置太長不然一遇到網(wǎng)絡(luò)波動(dòng)用戶界面上會(huì)出現(xiàn)“卡死”感。第二是請(qǐng)求要帶Cache-Control請(qǐng)求頭避免 CDN 節(jié)點(diǎn)緩存了舊清單導(dǎo)致客戶端反復(fù)拿到舊數(shù)據(jù)。下載更新包時(shí)強(qiáng)烈建議用分段下載或斷點(diǎn)續(xù)傳。我自己的經(jīng)驗(yàn)是用HttpClient的Range頭實(shí)現(xiàn)斷點(diǎn)續(xù)傳下載過程中寫入臨時(shí)文件記錄已下載字節(jié)數(shù)。等到全部下載完成后再校驗(yàn)哈希校驗(yàn)通過才把臨時(shí)文件改名到正式位置。這樣做能避免下載到一半的損壞文件覆蓋正式文件。public async Task DownloadUpdateAsync(string url, string localFile, long expectedSize, CancellationToken ct) { var tempFile localFile .part; using var client new HttpClient(); long existingLength 0; if (File.Exists(tempFile)) existingLength new FileInfo(tempFile).Length; if (existingLength 0) client.DefaultRequestHeaders.Range new RangeHeaderValue(existingLength, null); using var response await client.GetAsync(url, HttpCompletionOption.ResponseHeadersRead, ct); await using var source await response.Content.ReadAsStreamAsync(ct); await using var target new FileStream(tempFile, FileMode.Append, FileAccess.Write); await source.CopyToAsync(target, 81920, ct); if (target.Length ! expectedSize) throw new IOException($文件大小不匹配期望 {expectedSize}實(shí)際 {target.Length}); // 下載完整后替換正式文件 File.Move(tempFile, localFile, true); }這里的81920是緩沖區(qū)大小這個(gè)數(shù)值在多數(shù)網(wǎng)絡(luò)環(huán)境下表現(xiàn)較好過小會(huì)導(dǎo)致頻繁系統(tǒng)調(diào)用過大會(huì)浪費(fèi)內(nèi)存。實(shí)際使用中可以按需調(diào)整。3.3 更新進(jìn)程與主程序解耦.NET 桌面應(yīng)用更新時(shí)最大的難點(diǎn)是程序文件正在被進(jìn)程占用。你在主程序里執(zhí)行替換自身文件的操作Windows 會(huì)拋出訪問被拒絕異常。解決辦法是把更新動(dòng)作剝離到獨(dú)立的更新進(jìn)程里。比較通用的做法是這樣的主程序發(fā)現(xiàn)新版本后把下載好的更新包路徑、目標(biāo)目錄、重啟參數(shù)通過命令行傳給updater.exe。updater.exe是一個(gè)輕量級(jí)的獨(dú)立程序它啟動(dòng)后等待主程序退出然后完成解壓、替換、重新啟動(dòng)主程序的流程。這樣可以做到“更新過程中主程序完全關(guān)閉文件不被占用”。主程序在退出前還可以發(fā)送一個(gè)“心跳通知”給更新器更新器收到通知后再開始替換避免主程序還沒完全釋放 DLL 文件就開始操作。還有一點(diǎn)容易被忽略更新器本身也需要更新。由于updater.exe是在主程序外部運(yùn)行的它不會(huì)隨主程序一起被替換時(shí)間一長會(huì)積累老版本兼容性問題。為了應(yīng)對(duì)這種情況可以在更新包里同時(shí)攜帶新版本的updater.exe更新器在替換主程序前先把自己復(fù)制一份到臨時(shí)目錄然后從臨時(shí)副本運(yùn)行后續(xù)操作從而實(shí)現(xiàn)更新器的自更新。3.4 云端存儲(chǔ)與內(nèi)容分發(fā)配置要點(diǎn)如果選擇對(duì)象存儲(chǔ)加 CDN 的方式有三個(gè)配置細(xì)節(jié)要注意。第一是權(quán)限設(shè)置。更新文件必須允許匿名讀取但存儲(chǔ)桶內(nèi)的文件列表盡量不對(duì)外暴露?？梢灾苯釉O(shè)置私讀然后通過 CDN 的公網(wǎng)地址分發(fā)如果必須直接用存儲(chǔ)桶域名訪問則開啟私有讀寫配合簽名 URL 給客戶端下發(fā)臨時(shí)下載地址。我這里更推薦 CDN 回源的方式因?yàn)?CDN 節(jié)點(diǎn)會(huì)緩存文件能大幅降低源站的流量成本。第二是緩存刷新。發(fā)新版本后更新清單文件和更新包需要立即生效。如果 CDN 緩存時(shí)間設(shè)置過長用戶可能拉取到舊的清單導(dǎo)致更新機(jī)制整體失效。解決方法是發(fā)布時(shí)手動(dòng)刷新更新清單對(duì)應(yīng) URL 的緩存或者把清單文件的Cache-Control設(shè)置為no-cache。第三是跨域問題。桌面客戶端請(qǐng)求更新服務(wù)一般不涉及瀏覽器同源策略但如果你在開發(fā)環(huán)境中用 Electron 或 WebView 做更新界面就要注意 CORS 配置。寧可提前把允許的來源配置好也不要等聯(lián)調(diào)報(bào)錯(cuò)再臨時(shí)補(bǔ)。4. 常見問題與排查技巧實(shí)錄4.1 文件被占用導(dǎo)致更新失敗這個(gè)問題在 Windows 下最常見尤其是主程序含有多個(gè) DLL 或服務(wù)進(jìn)程時(shí)。我的排查經(jīng)驗(yàn)是更新失敗時(shí)先看日志里的異常類型如果異常是IOException且消息中帶有“being used by another process”基本就是文件占用。解決方向有三個(gè)一是把更新程序移到獨(dú)立進(jìn)程這是最徹底的方案二是讓主程序在更新前調(diào)用GC.Collect()顯式釋放托管資源同時(shí)關(guān)閉所有指向程序目錄的文件句柄三是如果程序有多個(gè)進(jìn)程協(xié)同工作要確保所有相關(guān)進(jìn)程都退出后再替換文件。曾經(jīng)有個(gè)項(xiàng)目主程序退出了但有一個(gè)后臺(tái)守護(hù)進(jìn)程還持有 DLL 句柄導(dǎo)致更新一直失敗排查了很久才發(fā)現(xiàn)是這個(gè)原因。4.2 殺毒軟件誤報(bào)更新包.NET 程序打包成壓縮包或安裝程序后很容易被部分安全軟件誤判。如果更新包被查殺用戶就會(huì)在更新第一步遭遇失敗。比較有效的處理辦法一是給更新包做正規(guī)的代碼簽名能明顯降低誤報(bào)率二是避免使用過于冷門的壓縮殼或混淆工具三是不要頻繁改變打包工具安全軟件對(duì)已經(jīng)見過多次的打包格式更友好。如果誤報(bào)已經(jīng)發(fā)生需要及時(shí)聯(lián)系誤報(bào)廠商申訴并準(zhǔn)備好簽名證書、哈希值等證明材料。還遇到過一種情況殺毒軟件把更新器當(dāng)成惡意軟件攔截因?yàn)樗哂小白晕覐?fù)制并改寫其他程序”的典型行為。這種場景下除了代碼簽名還可以考慮在更新器中加入向用戶展示更新來源信息的界面并保持發(fā)布頻率穩(wěn)定逐步建立信譽(yù)。4.3 多實(shí)例同時(shí)更新造成的沖突如果用戶在機(jī)器上同時(shí)開了兩個(gè)主程序?qū)嵗齼蓚€(gè)實(shí)例可能同時(shí)下載更新包、同時(shí)啟動(dòng)更新器導(dǎo)致文件替換操作互相覆蓋。最簡單的處理辦法是使用全局互斥量。更新器啟動(dòng)時(shí)先嘗試獲取命名互斥鎖拿不到鎖就直接退出由已經(jīng)運(yùn)行的更新器完成任務(wù)。還要考慮更新完成后重啟主程序的動(dòng)作如果更新器殺掉了全部主進(jìn)程用戶正在編輯的未保存數(shù)據(jù)可能丟失。穩(wěn)妥做法是更新前監(jiān)測主進(jìn)程是否有未保存狀態(tài)由主程序決定是否允許立即更新而不是更新器強(qiáng)制操作。我踩過這個(gè)坑后來改成“主程序在收到更新通知后先保存現(xiàn)場再主動(dòng)退出并拉起更新器”的流程。4.4 更新后配置丟失很多桌面程序的配置文件位于程序目錄下更新時(shí)如果把整個(gè)目錄替換掉配置就隨著舊目錄一起沒了。解決思路是嚴(yán)格區(qū)分“程序文件”和“數(shù)據(jù)文件”。更新包內(nèi)只包含程序文件數(shù)據(jù)文件通過更新清單里的白名單排除替換文件時(shí)跳過白名單中的路徑。如果配置在AppData目錄下通常不會(huì)被更新操作波及。但如果是存放在程序目錄下的config.json、appsettings.json就一定要在更新流程里做保護(hù)。最保險(xiǎn)的是在更新前把這類文件備份到臨時(shí)目錄替換完成后自動(dòng)還原更長期的做法是把用戶配置遷移到獨(dú)立位置從源頭上避免被更新覆蓋。4.5 網(wǎng)絡(luò)中斷導(dǎo)致的半程更新弱網(wǎng)環(huán)境下下載大更新包很容易中斷。表面上看有了斷點(diǎn)續(xù)傳功能后重新下載只需從斷點(diǎn)開始但這會(huì)引入一個(gè)新的問題服務(wù)器上的更新包可能已經(jīng)重新生成了文件和之前下載的不是同一個(gè)續(xù)傳得到的是一個(gè)“混血文件”哈希校驗(yàn)必然失敗。我的處理方式是在下載請(qǐng)求的 URL 中帶一個(gè)文件標(biāo)識(shí)參數(shù)比如基于文件內(nèi)容計(jì)算的 ETag 或版本哈希。斷點(diǎn)續(xù)傳前先確認(rèn)當(dāng)前 URL 對(duì)應(yīng)的標(biāo)識(shí)沒變?nèi)绻兞司蛠G棄臨時(shí)文件重新下載。這個(gè)檢查邏輯不復(fù)雜但能避免很多“下載失敗-重試-再失敗”的循環(huán)。5. 不同方案橫向?qū)Ρ扰c真實(shí)選型經(jīng)驗(yàn)5.1 ClickOnce 的適用邊界ClickOnce 是 .NET 早期自帶的一套發(fā)布和更新機(jī)制開發(fā)成本極低部署也方便。它適合以下幾類場景用戶量不大、更新頻率不高、對(duì)更新流程沒有定制需求的輕量應(yīng)用。但 ClickOnce 在真實(shí)使用中有不少限制。它的安裝位置特殊用戶無法直接找到可執(zhí)行文件和某些需要管理員權(quán)限的驅(qū)動(dòng)或 COM 組件交互時(shí)容易出問題。另一個(gè)問題是ClickOnce 更新依賴于manifest和.application文件的正確處理一旦部署環(huán)境對(duì) MIME 類型或證書信任配置不正確客戶端更新就會(huì)異常。如果項(xiàng)目超過一定復(fù)雜度我會(huì)傾向于不用 ClickOnce因?yàn)樗m然簡單但“簡單”是以放棄控制權(quán)為代價(jià)的。5.2 開源更新組件的典型特點(diǎn)開源更新組件的價(jià)值是幫你把更新流程的基礎(chǔ)工作做掉比如解析清單、下載文件、啟動(dòng)更新器。它們的共同特點(diǎn)是開箱即用社區(qū)文檔也比較齊全。使用這類組件時(shí)有幾條注意事項(xiàng)。第一是版本兼容性某些組件對(duì) .NET 版本有硬性要求升級(jí)主框架前要先驗(yàn)證更新組件是否兼容。第二是許可證約束不是所有開源組件都允許閉源商業(yè)應(yīng)用集成用之前要把授權(quán)策略看清楚。第三是更新組件的維護(hù)頻率長期不活躍的項(xiàng)目要謹(jǐn)慎引入否則出了問題只能自己改源碼。我個(gè)人不建議對(duì)這類組件做大規(guī)模深度定制。更新流程本身涉及很多邊界情況改動(dòng)越深后續(xù)合并上游更新越困難。能用配置解決的不要改源碼。5.3 云托管方案的收益與限制云托管方案是最近幾年比較流行的選擇。它把更新包托管、版本管理、下載統(tǒng)計(jì)、灰度發(fā)布這些能力做成平臺(tái)服務(wù)客戶端只需要集成 SDK。對(duì)于缺少服務(wù)端開發(fā)資源的團(tuán)隊(duì)這是最省事的路徑。使用這種方案的代價(jià)是綁定平臺(tái)。如果平臺(tái)服務(wù)中斷或調(diào)整接口策略應(yīng)用的更新鏈路會(huì)受連帶影響。另外部分平臺(tái)按下載流量收費(fèi)如果用戶基數(shù)大、更新包也大費(fèi)用需要提前估算。我在選型時(shí)會(huì)把“脫離平臺(tái)后的遷移成本”作為重要考量比較理想的狀態(tài)是云服務(wù)只作為可替換的實(shí)現(xiàn)核心更新協(xié)議仍保持自研這樣切換成本可控。5.4 我的推薦組合自建協(xié)議 對(duì)象存儲(chǔ) 輕量更新器說了這么多如果讓我在真實(shí)項(xiàng)目里直接選我會(huì)推薦下面這套組合自建更新協(xié)議就是上面那個(gè)manifest.json 哈希校驗(yàn) 獨(dú)立更新進(jìn)程的方案存儲(chǔ)層用對(duì)象存儲(chǔ)分發(fā)層用 CDN客戶端用開源組件框架或自研輕量更新器。這套組合的好處是協(xié)議簡單可控不管是后續(xù)擴(kuò)展灰度發(fā)布還是接入統(tǒng)計(jì)系統(tǒng)都很方便對(duì)象存儲(chǔ)的成本遠(yuǎn)低于自建服務(wù)器CDN 能保證大文件下載速度。整體開發(fā)量也不算大一個(gè)成熟開發(fā)者在兩三天內(nèi)就能把核心鏈路跑通。如果你實(shí)在不想自己寫更新協(xié)議那優(yōu)先選擇云托管服務(wù)把更多精力放在主程序本身。但要記得預(yù)留反向遷移預(yù)案。我自己經(jīng)歷的多次更新系統(tǒng)重構(gòu)中最難的從來不是寫代碼而是把一個(gè)已經(jīng)散落在用戶機(jī)器上的老版本通知機(jī)制平滑切換過來。所以無論選什么方案兼容老版本客戶端這條底線不能丟。補(bǔ)充這些容易被忽略的工具鏈細(xì)節(jié)更新系統(tǒng)上線后日志收集和監(jiān)控同樣重要。更新失敗原因往往千奇百怪沒有日志就像在黑夜里找鑰匙。建議客戶端至少記錄四類日志檢查更新是否成功、下載是否成功、哈希校驗(yàn)是否通過、替換階段是否成功。日志文件按照日期和進(jìn)程 ID 命名保留最近五天即可。另一個(gè)容易被忽略的問題是系統(tǒng)時(shí)間。如果用戶機(jī)器時(shí)間不正確版本比較邏輯可能異常證書有效性判斷也會(huì)失效。更新檢查邏輯里要避免依賴本地時(shí)間作為“新版本發(fā)布時(shí)間”的判斷依據(jù)而應(yīng)該以服務(wù)端返回的版本號(hào)為唯一依據(jù)。時(shí)間戳字段僅作為參考和展示不參與更新決策。更新策略上還有一個(gè)建議不要一上線就全量推送?？梢园迅路峙畏帕勘热缦茸?5% 的用戶看到更新通知觀察崩潰率和回退率正常后再放量到 100%。即使你的更新包測試再充分也免不了在真實(shí)用戶環(huán)境中碰到兼容性問題灰度是一道重要的安全網(wǎng)。我實(shí)際維護(hù)更新系統(tǒng)時(shí)遇到過一個(gè)小場景某個(gè)發(fā)布版本意外引入了崩潰問題用戶無感更新后應(yīng)用反復(fù)閃退。由于沒有提前做灰度等發(fā)現(xiàn)問題時(shí)已波及大量用戶。后來團(tuán)隊(duì)把更新流程加了“強(qiáng)制回滾到上一版本”的遠(yuǎn)程指令才算把影響面控制住。但那個(gè)過程相當(dāng)狼狽。每次發(fā)布都建議先推給測試機(jī)和少量種子用戶驗(yàn)證別貪圖省那幾分鐘。從這個(gè)案例里沉淀下來的經(jīng)驗(yàn)是自動(dòng)更新的流程設(shè)計(jì)里永遠(yuǎn)要把“出問題時(shí)如何最快止損”放在和“如何最快升級(jí)”同等重要的位置。回滾按鈕不是擺設(shè)而是救命稻草。