簡(jiǎn)介SharpCompress 0.37.2 為面向 .NET 開發(fā)者的跨版本壓縮解壓庫資源適用于在 C# 項(xiàng)目中便捷處理 zip、tar、7z 等常見歸檔格式可有效降低文件流讀寫與壓縮算法集成的復(fù)雜度。該壓縮包共包含 11 個(gè)文件以針對(duì) net8.0、net6.0、netstandard2.1、netstandard2.0 及 net462 等目標(biāo)框架編譯的 SharpCompress.dll 為核心同時(shí)附帶 XML 文檔、NuGet 包描述文件、程序集簽名及 README 說明便于開發(fā)者按項(xiàng)目環(huán)境選取引用并快速查閱 API 用法。整個(gè)資源大小約 1.19MB輕量實(shí)用。已有 87 人下載學(xué)習(xí)適合需要引入成熟壓縮方案的中高級(jí) .NET 工程師或需要在離線場(chǎng)景集成庫文件的項(xiàng)目團(tuán)隊(duì)。通過該壓縮包可直接獲取對(duì)應(yīng)版本的托管程序集、包元數(shù)據(jù)與文檔免去在線安裝的額外步驟同時(shí)核驗(yàn)包簽名信息有助于提升構(gòu)建與交付的可靠性。1. SharpCompress 是什么解壓界的瑞士軍刀但別被 0.37.2 這個(gè)版本號(hào)騙了如果你在 .NET 項(xiàng)目里被 rar、7z、tar.gz 這些格式搞得焦頭爛額sharpcompress.0.37.2 這個(gè) NuGet 包應(yīng)該在你的還原清單里。它不是微軟官方組件卻在開源社區(qū)里被廣泛當(dāng)作多格式壓縮的默認(rèn)選擇。這套 0.37.2 版本體積不大但把 zip、tar、rar、7z 的讀寫統(tǒng)一在了一套流式 API 里寫起來比反復(fù)切換底層命令要順手得多。這篇筆記從選型理由講到踩坑記錄適合剛接手帶歷史包袱的壓縮模塊、或者想給工具箱補(bǔ)一個(gè)多格式庫的 .NET 開發(fā)者。需要提醒的是這個(gè)版本號(hào)自帶一些歷史含義后面我會(huì)單獨(dú)說明。2. 為什么 SharpCompress 能一次搞定 zip、rar、7z格式支持與選型邏輯2.1 SharpCompress 與 System.IO.Compression 的邊界什么時(shí)候該換庫很多項(xiàng)目一開始用 System.IO.Compression 處理 zip發(fā)現(xiàn)也能跑但需求一復(fù)雜就卡住。微軟官方庫只內(nèi)置了 zip、gzip、tar 的一部分rar 和 7z 完全不在支持范圍。如果有人給你一個(gè)加密的 rar 分卷包官方庫只能干瞪眼。SharpCompress 的定位就是補(bǔ)上這些缺位它同時(shí)支持 zip、tar、tar.gz、tar.bz2、rar、7z、gzip、bzip2、xz 的讀取以及 zip、tar、gzip、bzip2 的寫入。每次版本更新都會(huì)修正一些格式細(xì)節(jié)0.37.2 這個(gè)版本在 rar 5 的處理上已經(jīng)比較成熟。我一般會(huì)建議按這個(gè)邊界選型如果業(yè)務(wù)只用標(biāo)準(zhǔn) zip并且需要和 Java 系互傳老老實(shí)實(shí)用 System.IO.Compression如果出現(xiàn) rar、7z、加密分卷、自定義擴(kuò)展名或者需要流式讀取壓縮包內(nèi)部條目就換 SharpCompress。還有一個(gè)容易被忽略的理由官方庫對(duì) zip 的壓縮選項(xiàng)控制很有限SharpCompress 的 Writer 支持按條目指定壓縮類型和壓縮等級(jí)這在處理混合內(nèi)容時(shí)非常靈活。比如日志文件用快速壓縮圖片文件用存儲(chǔ)模式避免 CPU 空耗。選型時(shí)也要注意版本號(hào)的策略。SharpCompress 的版本號(hào)不是單純的功能遞增0.37.2 屬于較新的穩(wěn)定系列API 與早期 0.30 系列有差異。有些老教程里寫的 ArchiveFactory.WriteTo 在當(dāng)前版本已經(jīng)變了網(wǎng)上搜到的代碼如果用的是舊接口編譯時(shí)會(huì)直接報(bào)錯(cuò)。這也是我在這里堅(jiān)持寫 0.37.2 實(shí)際可用代碼的原因——版本差異是這個(gè)庫最大的學(xué)習(xí)成本之一。2.2 核心對(duì)象Reader、Writer 與 Archive 的設(shè)計(jì)差異SharpCompress 提供了三套風(fēng)格不同的 API。第一套是只讀的 Reader面向流式讀取壓縮包適合邊讀邊處理內(nèi)存占用低。第二套是 Writer面向?qū)懭肟梢灾饤l添加條目并控制壓縮參數(shù)。第三套是 Archive面向隨機(jī)訪問適合需要查目錄、按條目不連續(xù)讀取的場(chǎng)景。三者各有分工用錯(cuò)會(huì)導(dǎo)致性能問題。例如用 Archive 去讀一個(gè)巨大的 tar 包它可能把整個(gè)條目目錄讀進(jìn)內(nèi)存而用 Reader 只能順序讀無法跳回上一條。在實(shí)際項(xiàng)目中我傾向于把 Reader 當(dāng)作默認(rèn)選擇。對(duì)于絕大多數(shù)“從壓縮包里讀出文件流并轉(zhuǎn)發(fā)出去”的場(chǎng)景順序讀就夠了而且 Reader 天然支持從流中讀取不需要知道文件大小。Archive 更適合需要反復(fù)讀取、或者需要讀取分卷壓縮包的時(shí)候。Writer 則是寫入時(shí)不二之選它和 Reader 共享一套條目抽象所以用 Writer 寫出來的包用 Reader 讀時(shí)不會(huì)出現(xiàn)奇怪的路徑兼容問題。這里有一個(gè)設(shè)計(jì)上的坑Reader 和 Archive 的讀取粒度不同。Reader 需要先進(jìn)入某個(gè)條目再讀取該條目的流Archive 則可以直接通過 entry.Key / entry.OpenEntryStream() 獲取條目。不要混用。常見錯(cuò)誤是先用 Archive 枚舉根目錄再試圖用 Reader 讀取同一個(gè)壓縮包結(jié)果 Reader 會(huì)從頭開始無法定位。如果確實(shí)需要隨機(jī)訪問全程用 Archive如果想順序解壓并控制內(nèi)存全程用 Reader。2.3 從 sharpcompress.0.37.2 的包結(jié)構(gòu)看版本約定剛解壓 sharpcompress.0.37.2.zip 時(shí)你會(huì)看到 lib 目錄下按 netstandard2.0、net462 等不同目標(biāo)框架分了好幾個(gè)子目錄。這不是冗余是因?yàn)榈讓?API 在不同 .NET 版本上的實(shí)現(xiàn)有差異。選擇對(duì)應(yīng)的 DLL 時(shí)要看你項(xiàng)目的目標(biāo)框架。如果你用 .NET 6可以直接引用 netstandard2.0 版本兼容性最好。如果誤引用了低版本對(duì)應(yīng)的 DLL在運(yùn)行時(shí)可能出現(xiàn)方法未找到之類的異常。這個(gè)包里還有一個(gè) SharpCompress.Desktop 的區(qū)分。桌面框架下某些格式比如舊版 RAR 的 Unicode 文件名會(huì)有額外處理。在 .NET Core 上該庫會(huì)退回到純托管實(shí)現(xiàn)性能略有下降但功能不變。理解了這一點(diǎn)當(dāng)你遇到“同樣的代碼在 Framework 上正常、在 Core 上拋異常”的問題時(shí)就不會(huì)去懷疑業(yè)務(wù)邏輯而是優(yōu)先檢查是否踩到了框架差異。版本約定的另一層含義是0.37.2 是發(fā)行包對(duì)應(yīng)的源碼標(biāo)簽可以在倉庫的歷史提交里找到。如果你需要修復(fù)某個(gè) bug建議直接拉對(duì)應(yīng)版本的源碼構(gòu)建而不是拿主分支的代碼去改。因?yàn)橹鞣种Э赡芤呀?jīng)引入破壞性變更編譯出來和 NuGet 包行為不一致。我見過有人改了主分支源碼想替換包結(jié)果 API 簽名對(duì)不上最后被迫降級(jí)。另外建議在項(xiàng)目里鎖定這個(gè)包版本因?yàn)樾掳姹究赡軙?huì)改變 ReaderOptions 的默認(rèn)值升包后出現(xiàn)行為差異這類問題在上線前很難發(fā)現(xiàn)。3. 把 sharpcompress.0.37.2 跑起來最小解壓與壓縮代碼3.1 用 ZipArchive 完成最小解壓代碼與參數(shù)說明先來一段最常見的解壓代碼用 SharpCompress 讀取 zip 文件里的所有條目并輸出到指定目錄。using SharpCompress.Readers; using (var stream File.OpenRead(C:\data\backup.zip)) using (var reader ReaderFactory.Open(stream)) { while (reader.MoveToNextEntry()) { if (!reader.Entry.IsDirectory) { reader.WriteEntryToDirectory(C:\data\extracted, new ExtractionOptions { ExtractFullPath true, Overwrite true }); } } }這段代碼的邏輯是先用文件流打開壓縮包再用ReaderFactory.Open自動(dòng)識(shí)別格式。MoveToNextEntry在內(nèi)部會(huì)判斷當(dāng)前流屬于哪種壓縮類型并將條目指針移動(dòng)到下一條。遇到目錄條目直接跳過否則寫入目標(biāo)目錄。ExtractionOptions里的ExtractFullPath表示保持壓縮包內(nèi)的相對(duì)路徑Overwrite決定是否覆蓋已存在文件。兩個(gè)參數(shù)建議顯式設(shè)置因?yàn)槟J(rèn)值在不同版本里有調(diào)整不寫清楚容易產(chǎn)生“解出來少了一半文件”的錯(cuò)覺。這里有一個(gè)性能注意點(diǎn)WriteEntryToDirectory內(nèi)部會(huì)對(duì)每個(gè)條目打開目標(biāo)文件并復(fù)制流但如果你需要二次處理比如重命名、去重、過濾大文件就不要用這個(gè)方法而是自己讀取條目的流?？聪旅娴淖凅wusing var reader ReaderFactory.Open(stream); while (reader.MoveToNextEntry()) { if (reader.Entry.IsDirectory) continue; if (reader.Entry.Size 100 * 1024 * 1024) continue; // 跳過 100 MB 以上條目 using var entryStream reader.OpenEntryStream(); using var output File.Create(Path.Combine(targetDir, reader.Entry.Key)); entryStream.CopyTo(output); }由OpenEntryStream返回的流只能在這一個(gè)條目?jī)?nèi)讀取移動(dòng)指針到下一個(gè)條目后之前條目對(duì)應(yīng)的流就失效。所以循環(huán)內(nèi)不能緩存多個(gè)條目的流必須立刻消費(fèi)。Entry.Size在讀取時(shí)就可以拿到適合做前置過濾。如果目標(biāo)目錄不存在需要先Directory.CreateDirectory否則File.Create會(huì)拋目錄找不到的異常別問我怎么知道的。3.2 用 Writer 生成 tar.gz 壓縮包分步實(shí)現(xiàn)解壓之外寫入一個(gè) tar.gz 包是常見的交付需求。SharpCompress 的 Writer 支持單格式寫入但 tar.gz 其實(shí)是兩個(gè)步驟先生成 tar 流再用 gzip 套一層。常見做法是用WriterFactory.Open傳一個(gè) gzip 壓縮流給 TarWriter。using var fileStream File.Create(C:\data\output.tar.gz); using var gzipStream new GZipStream(fileStream, CompressionLevel.Optimal); using var writer WriterFactory.Open(ArchiveType.Tar, gzipStream); writer.Write(C:\data\file1.txt, file1.txt); writer.Write(C:\data\pic.png, images\pic.png);這里WriterFactory.Open的第一個(gè)參數(shù)指定內(nèi)部格式第二個(gè)參數(shù)是輸出流。要點(diǎn)是gzip 流在外層tar 流在邏輯上屬于內(nèi)層。Write方法有多個(gè)重載最簡(jiǎn)單的是傳源文件路徑和條目名。如果需要記錄條目標(biāo)時(shí)間、權(quán)限等信息可以傳額外的 FileInfo。注意Write執(zhí)行時(shí)并不會(huì)立即將內(nèi)容寫入文件流它會(huì)在條目數(shù)據(jù)復(fù)制完畢后刷新所以不要提前關(guān)閉gzipStream要等 writer 釋放后再釋放外層流。實(shí)際項(xiàng)目中經(jīng)常要壓縮整個(gè)目錄手動(dòng)逐條Write太累?？梢员闅v目錄后寫成遞歸函數(shù)但要注意路徑分隔符。統(tǒng)一把條目名里的\替換成/否則在 Linux 上解壓會(huì)看到反斜杠文件名。這個(gè)細(xì)節(jié)很容易翻車。3.3 內(nèi)存流與文件流的切換避免把大文件讀進(jìn)內(nèi)存很多初學(xué)代碼喜歡寫byte[] data File.ReadAllBytes再塞進(jìn) MemoryStream 交給壓縮庫。這種寫法在小文件沒問題但一旦遇到幾百 MB 的包內(nèi)存立刻告急。SharpCompress 的所有 API 都接受流所以盡量讓文件流貫穿始終。以下寫法是正確的姿勢(shì)using var input File.OpenRead(C:\data\big.zip); using var reader ReaderFactory.Open(input); while (reader.MoveToNextEntry()) { // 直接消費(fèi)不經(jīng)過 MemoryStream }如果你必須把解壓結(jié)果放到內(nèi)存里比如后端接口需要把壓縮包內(nèi)容轉(zhuǎn)成 JSON 后再透?jìng)髂且惨刂茊蝹€(gè)條目的體積。一個(gè)實(shí)用的策略是按條目大小做開關(guān)小于 10 MB 讀進(jìn)內(nèi)存大于則寫入臨時(shí)文件。這樣既滿足接口的即時(shí)處理又不至于把進(jìn)程內(nèi)存撐爆。Entry.Size在流式讀取時(shí)是可用的所以這個(gè)判斷可以放在OpenEntryStream之前。需要格外注意的是ReaderFactory.Open在讀流時(shí)并不預(yù)讀整個(gè)壓縮包它只是根據(jù)文件頭判斷格式。所以如果流被包裝過比如加了一層自定義加密直接拋異常。這不算 bug而是設(shè)計(jì)如此任何壓縮庫都必須看到標(biāo)準(zhǔn)的文件頭才能工作。如果你的包是加密后再做 base64 傳輸?shù)谋仨毾冉饷苓€原成原始?jí)嚎s流。4. 加密、分卷與大文件的流式處理代碼怎么寫才不翻車這一章解決的是最容易讓人放棄的三個(gè)場(chǎng)景加密、分卷、流式。這三個(gè)需求背后都隱藏著一些不打開源碼就看不出的約定但只要把參數(shù)和調(diào)用姿勢(shì)寫對(duì)SharpCompress 能處理得相當(dāng)干凈。4.1 Rar 與 7z 的加密解壓密碼參數(shù)怎么傳加密是壓縮領(lǐng)域的大坑。SharpCompress 對(duì) rar 和 7z 的加密支持程度不同。rar 的傳統(tǒng)加密rar2、rar4可以通過ReaderOptions.Password直接解壓而 rar5 的某些加密頭處理在 0.37.2 版本已經(jīng)可用但不是所有變體都支持。7z 則只支持 AES-256 加密的條目如果你遇到“密碼正確但解不開”的情況先確認(rèn)壓縮時(shí)選的加密方式。一個(gè)正確的加密解壓寫法var options new ReaderOptions { Password your-password, LookForHeader true }; using var reader ReaderFactory.Open(fileStream, options); while (reader.MoveToNextEntry()) { reader.WriteEntryToDirectory(targetDir, new ExtractionOptions { ExtractFullPath true, Overwrite true }); }這里的LookForHeader會(huì)讓庫在流中搜索文件頭而不是假設(shè)流起始就是文件頭。這個(gè)參數(shù)對(duì)于從大文件中提取內(nèi)嵌壓縮包很有用但也會(huì)增加掃描耗時(shí)。在確定壓縮包就是完整文件的場(chǎng)景下建議設(shè)為false以提升性能。密碼錯(cuò)誤時(shí)MoveToNextEntry或讀取條目流時(shí)會(huì)拋出密碼錯(cuò)誤異常不要在主循環(huán)里只 catch 一次就以為全部處理完畢要區(qū)分條目級(jí)別。注意同一個(gè)加密包在 Windows 和 Linux 上對(duì)密碼的處理可能不一致和系統(tǒng)區(qū)域的 UTF-8 設(shè)置有關(guān)。遇到詭異問題時(shí)先嘗試把密碼用 ASCII 重新輸入。另一個(gè)細(xì)節(jié)不要把密碼寫死在代碼里。日志、配置文件都可能被掃描到。我一般把密碼放環(huán)境變量配合IConfiguration注入。壓縮包來源不可信時(shí)更要注意不要用同一套密碼解壓所有文件否則相當(dāng)于把鑰匙交給了不可控的代碼路徑。4.2 分卷壓縮 Volume 的處理連續(xù)文件的聚合邏輯rar 分卷.part1.rar、.part2.rar和 7z 分卷.7z.001、.7z.002是另一個(gè)高頻需求。SharpCompress 的 Reader 本身不支持直接“吃”多個(gè)分卷流需要你自己把多個(gè)文件流串起來。常見做法是打開第一個(gè)分卷其余分卷按順序作為追加流傳入。一個(gè)實(shí)用的分卷解壓實(shí)現(xiàn)var files Directory.GetFiles(C:\data\, *.part*.rar) .OrderBy(f f, StringComparer.OrdinalIgnoreCase) .ToArray(); using var primary File.OpenRead(files[0]); using var reader ReaderFactory.Open(primary, new ReaderOptions { Password password }); while (reader.MoveToNextEntry()) { reader.WriteEntryToDirectory(C:\data\out, new ExtractionOptions { ExtractFullPath true }); }但這其實(shí)只讀到了第一個(gè)分卷后面的分卷不會(huì)被自動(dòng)識(shí)別。SharpCompress 提供了 Volume 相關(guān)對(duì)象但不同格式的處理方式不一致。對(duì)于 rar你需要手動(dòng)處理跨卷?xiàng)l目的拼接。最簡(jiǎn)單的方案是先解壓第一個(gè)分卷當(dāng)某個(gè)條目的流讀完但校驗(yàn)失敗時(shí)關(guān)閉當(dāng)前流并打開下一個(gè)分卷再繼續(xù)。實(shí)際操作時(shí)我建議直接調(diào)用ArchiveFactory.Open打開第一個(gè)文件它會(huì)自動(dòng)尋找同目錄下的分卷文件因?yàn)?Archive 模式實(shí)現(xiàn)了分卷發(fā)現(xiàn)邏輯。所以分卷場(chǎng)景請(qǐng)用 Archive 而不是 Reader。代碼大致是using var archive ArchiveFactory.Open(files[0]); foreach (var entry in archive.Entries) { entry.WriteToDirectory(C:\data\out, new ExtractionOptions { ExtractFullPath true, Overwrite true }); }注意分卷文件的命名必須連續(xù)且在同一目錄否則自動(dòng)發(fā)現(xiàn)會(huì)失敗。分卷文件缺失時(shí)庫拋出的異常信息往往只寫“CRC 錯(cuò)誤”很容易讓人誤以為文件損壞。實(shí)際原因是后續(xù)分卷沒有找到。遇到這種異常時(shí)先檢查目錄里分卷是否齊全再檢查是不是命名大小寫不匹配。如果文件列表為空直接拋異常提示用戶要比后續(xù)解壓過程中的任何錯(cuò)誤都容易定位。4.3 流式讀取條目解壓不落盤直接進(jìn)管道把解壓數(shù)據(jù)直接傳給下一個(gè)處理模塊可以省去中間文件讀寫。這在處理 zip 內(nèi)含多個(gè)文件、需要逐一轉(zhuǎn)碼的場(chǎng)景非常有用。using var reader ReaderFactory.Open(input, new ReaderOptions { LeaveOpen true }); while (reader.MoveToNextEntry()) { using var s reader.OpenEntryStream(); // 直接寫入 HTTP 響應(yīng)流而不是寫到磁盤 s.CopyTo(httpResponse.Body); }LeaveOpen控制關(guān)閉 reader 時(shí)是否同時(shí)關(guān)閉底層流。如果底層流是網(wǎng)絡(luò)流就要設(shè)置LeaveOpen true否則 reader 釋放時(shí)會(huì)把網(wǎng)絡(luò)連接一起關(guān)掉。如果底層流是文件流設(shè)false會(huì)更省心。流式讀取的另一個(gè)好處是可以用CopyToAsync實(shí)現(xiàn)異步處理后面章節(jié)會(huì)講。有一個(gè)容易忽略的參數(shù)ReaderOptions.LeaveOpen在不同版本中默認(rèn)值不同。在 0.37.2 里默認(rèn)是 false。如果你是從舊版本升級(jí)上來的代碼之前沒顯式設(shè)置也能工作升級(jí)后可能突然報(bào)“流已關(guān)閉”這就是版本行為變化導(dǎo)致的。所以升級(jí)包之后務(wù)必檢查所有ReaderOptions的默認(rèn)值變更。對(duì)于超過 2GB 的壓縮包還要考慮文件流的緩存策略。打開底層 FileStream 時(shí)用FileOptions.SequentialScan可以降低文件系統(tǒng)預(yù)讀的沖擊反之如果你要隨機(jī)讀取多個(gè)條目用FileOptions.RandomAccess更合適。這也是我在處理超大包時(shí)常用的一個(gè)調(diào)優(yōu)點(diǎn)。5. SharpCompress 避坑指南五個(gè)現(xiàn)象背后的真實(shí)原因SharpCompress 整體設(shè)計(jì)不算復(fù)雜但真正遇到問題時(shí)網(wǎng)上資料很少大家基本靠試。我把這一年多在 0.37.2 上踩過的坑按頻率排了序下面五條最值得留意。每條都按“現(xiàn)象 → 原因 → 解決”的順序?qū)懩憧梢灾苯訉?duì)照自己的代碼排查。5.1 條目名亂碼不是庫的問題是壓縮包創(chuàng)建端的問題現(xiàn)象解壓 rar 或舊 zip文件名顯示成“錕斤拷”或省略號(hào)或者在 Linux 上解壓后路徑全變成下劃線。原因SharpCompress 默認(rèn)按 UTF-8 解析而老工具用 GBK/CP936 寫入。0.37.2 沒有暴露解碼器注入點(diǎn)所以你不能直接在 ReaderOptions 里指定編碼。解決讀取 entry.Key 后如果包含“?”或明顯亂碼把它按 ISO-8859-1 轉(zhuǎn)回 byte[]再按 GBK 重新編碼。示例代碼var rawBytes Encoding.Latin1.GetBytes(entry.Key); var corrected Encoding.GetEncoding(GBK).GetString(rawBytes);然后使用 corrected 作為目標(biāo)文件名。注意不要先寫成字符串再轉(zhuǎn)因?yàn)?.NET 的字符串已經(jīng)破壞了原始字節(jié)序列。這個(gè)坑很隱蔽但用一次就能記住。5.2 OutOfMemoryException多半是 Archive 模式惹的禍現(xiàn)象解壓幾個(gè) GB 的 tar 包進(jìn)程內(nèi)存飆到 1.5GB 并拋 OutOfMemoryException。原因ArchiveFactory.Open 會(huì)構(gòu)造整個(gè)文件列表的樹形結(jié)構(gòu)。tar 包如果包含幾十萬個(gè)文件這些對(duì)象占用的內(nèi)存遠(yuǎn)大于壓縮包本身。解決改用 ReaderFactory.Open 順序讀取因?yàn)?Reader 不會(huì)預(yù)加載條目目錄。如果確實(shí)需要 Archive 的隨機(jī)訪問嘗試分批處理先用 Reader 把索引落盤再按需定位。另外檢查是不是在 MoveToNextEntry 循環(huán)里用 MemoryStream 暫存了太多條目要確保每個(gè)條目處理完就釋放。5.3 同代碼不同運(yùn)行時(shí)的差異先查目標(biāo)框架再查異?，F(xiàn)象同一段解壓代碼在 .NET Framework 4.7.2 上正常遷移到 .NET 6 后拋 NotSupportedException。原因SharpCompress 內(nèi)部使用了一些桌面框架獨(dú)有的 API 處理舊格式這些分支在 netstandard2.0 目標(biāo)里被排除。0.37.2 的發(fā)行包里有多個(gè) DLL項(xiàng)目引用錯(cuò)了也會(huì)出現(xiàn)同樣現(xiàn)象。解決檢查項(xiàng)目生成的 deps.json 或程序集加載日志確認(rèn)加載的是 lib/netstandard2.0/SharpCompress.dll。如果還有問題不要試圖在 ReaderOptions 里找不存在的“編碼”或“兼容模式”屬性而是去查異常堆棧里的 “PlatformNotSupported” 標(biāo)志對(duì)應(yīng)到該版本源碼的條件編譯分支手動(dòng)繞過。5.4 遍歷慢得像死循環(huán)關(guān)掉 LookForHeader 試試現(xiàn)象一個(gè)只有 200 個(gè)條目的 zip 包MoveToNextEntry 循環(huán)卻卡了 10 秒。原因ReaderOptions 默認(rèn)的 LookForHeader 為 true它會(huì)從流的頭部或當(dāng)前位置向后掃描文件頭。這個(gè)掃描在完整文件流上完全多余還會(huì)把未壓縮的字節(jié)也拖進(jìn)檢測(cè)流程。解決在確定流起始就是壓縮包文件頭時(shí)顯式設(shè)置LookForHeader false。同時(shí)使用 FileStream 時(shí)不要用異步讀取模式這會(huì)引入額外緩沖。改完通常能把冷啟動(dòng)時(shí)間降一個(gè)數(shù)量級(jí)。如果包里條目數(shù)很大還可以考慮在解析前用文件流預(yù)讀一部分字節(jié)識(shí)別真實(shí)格式避免讓庫在未知位置反復(fù)試探。5.5 寫入壓縮包時(shí)進(jìn)度事件沒有觸發(fā)現(xiàn)象調(diào)用 writer.Write 時(shí)傳入的 IProgress 一次都沒回調(diào)。原因Write 方法的重載有很多只有帶 progress 參數(shù)的那個(gè)重載才會(huì)報(bào)告字節(jié)進(jìn)度。如果誤用了不帶 progress 的重載當(dāng)然沒有回調(diào)。解決使用writer.Write(entryPath, entryName, new FileInfo(entryPath), progress)重載。注意進(jìn)度是按字節(jié)計(jì)不是按條目計(jì)所以要先知道你寫入的總大小。想要百分比就用一個(gè)累加器除以總大小。如果你在解壓端看到進(jìn)度條亂跳多半是多個(gè)條目的進(jìn)度疊加了需要每個(gè)條目單獨(dú)建一個(gè) progress 實(shí)例。6. 進(jìn)階技巧并行解壓與性能驗(yàn)證的最后一公里當(dāng)單個(gè)壓縮包內(nèi)文件很多但彼此獨(dú)立很多人會(huì)想到多線程提升速度。但 SharpCompress 的 Reader 和 Archive 都不是線程安全的同一個(gè)流不能并發(fā)讀多個(gè)條目。正確做法是按壓縮包粒度并行而不是按條目并行。var zipFiles Directory.GetFiles(C:\data\, *.zip); await Parallel.ForEachAsync(zipFiles, new ParallelOptions { MaxDegreeOfParallelism 4 }, async (file, ct) { await Task.Run(() { using var reader ReaderFactory.Open(File.OpenRead(file)); while (reader.MoveToNextEntry()) { reader.WriteEntryToDirectory(C:\data\out, new ExtractionOptions { ExtractFullPath true, Overwrite false }); } }, ct); });MaxDegreeOfParallelism要按磁盤 IO 能力和目標(biāo)運(yùn)行環(huán)境調(diào)整。壓滿 CPU 并不等于壓滿磁盤通常 4 到 8 對(duì)機(jī)械盤已經(jīng)很高了。我一直習(xí)慣在跑完一批后對(duì)比總耗時(shí)與資源占用而不是盲目調(diào)大并發(fā)數(shù)。驗(yàn)證方式很簡(jiǎn)單用Stopwatch計(jì)時(shí)同時(shí)用Process.WorkingSet64觀察內(nèi)存。如果并發(fā)數(shù)翻倍但耗時(shí)沒降說明瓶頸在磁盤或解壓算法的單線程部分。我踩過一個(gè)很慘的坑曾經(jīng)為了提高解壓吞吐讓多個(gè)線程直接操作同一個(gè)ReaderFactory.Open出來的流結(jié)果出現(xiàn)大量 CRC 錯(cuò)誤。排查了一個(gè)下午最后才確認(rèn)流內(nèi)部有共享狀態(tài)根本不適合并發(fā)讀。那之后我給自己定了一條鐵律凡是MoveToNextEntry循環(huán)體里的操作永遠(yuǎn)不允許并行要并行就并行整個(gè)解壓流程。另外建議在發(fā)布前做一次小規(guī)模的性能基線測(cè)試固定同樣的輸入記錄 CPU、內(nèi)存和耗時(shí)。SharpCompress 的版本升級(jí)可能會(huì)改變默認(rèn)壓縮策略0.37.2 相比早期版本在 rar5 解壓上優(yōu)化明顯但 zip 寫入的壓縮等級(jí)默認(rèn)值有變動(dòng)。不要相信直覺跑一次數(shù)據(jù)再?zèng)Q定要不要加WriterOptions參數(shù)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取