最简单可靠的方式是用 Process.Start 调用 7-Zip 命令行，需确保 7z.exe 路径正确、参数顺序无误（如 a -t7z -mx=9）、UseShellExecute=false、空格路径加转义双引号，并捕获错误流与设置超时。
用 Process.Start 调用 7-Zip 命令行最简单可靠
只要系统已安装 7-Zip（或你自带 7z.exe），这是最快落地的方式。不需要 NuGet、不依赖 .NET 版本、压缩逻辑完全由 7-Zip 控制，稳定性高。
关键点：
-
7z.exe路径必须正确，推荐用绝对路径（如"C:\Program Files\7-Zip\7z.exe"），避免环境变量缺失导致失败 - 命令参数顺序不能错：
a -t7z -mx=9 archive.7z folder中a是添加（archive）命令，-t7z指定格式，-mx=9是最高压缩率 - 务必设置
UseShellExecute = false，否则无法捕获标准输出/错误，也容易因权限或空格路径崩溃 - 含空格的路径（如
"My Files"）必须用双引号包裹，且在参数字符串中要转义：""My Files""
用 SevenZipSharp 库需注意平台与线程模型
这个库封装了 7z.dll 的调用，看起来更“C# 化”，但实际踩坑不少：它依赖原生 7z.dll（x86/x64 必须匹配当前进程位数），且内部使用 STA 线程，若在 ASP.NET Core 或后台线程调用会直接抛 COMException。
实操建议：
- 只在 WinForms/WPF 等默认 STA 的 UI 线程中用；若必须在控制台或 Web 后台用，得手动创建 STA 线程并初始化
SevenZipCompressor - NuGet 安装
SevenZipSharp后，还需单独下载对应架构的7z.dll（官方版非 LZMA SDK 版），放到输出目录并设Copy to Output Directory = Copy always - 压缩回调（
CompressionFinished）不是主线程触发，更新 UI 需Invoke或Dispatcher.BeginInvoke - 不支持密码保护的 AES-256 加密（仅支持旧式 ZipCrypto），要用强加密还得切回命令行
别用 System.IO.Compression 生成 .7z 文件
.NET 原生的 ZipArchive 只支持 ZIP 格式（PK header），和 7z 完全无关。试图用它写 .7z 扩展名只会生成一个无法被 7-Zip 识别的损坏文件——打开时提示 "Cannot open file as archive"。
常见误解：
- 改文件扩展名为
.7z≠ 实际是 7z 格式 -
GZipStream或BrotliStream产出的是单文件流压缩，不是 7z 容器，不支持多文件、目录结构、加密、分卷 - 没有第三方 .NET 纯托管 7z 实现能稳定替代命令行或 SevenZipSharp（SharpCompress 支持读 7z，但写入能力极弱且无维护）
压缩大文件时记得处理超时与错误流
命令行调用看似简单，但实际生产中常因磁盘满、路径不存在、权限不足或 7z 崩溃而卡死或静默失败。
必须加的防护：
- 设置
Process.StartInfo.RedirectStandardError = true并读取StandardError，很多错误（如"ERROR: Can't open as archive"）只打在这里 - 给
Process.WaitForExit(300000)加超时（单位毫秒），防止挂起；超时后主动Kill() - 检查
Process.ExitCode：7-Zip 成功返回 0，警告是 1，错误通常是 2–7（如 2=用户中断，7=内存不足） - 若源路径含中文，确保
ProcessStartInfo.UseShellExecute = false且Encoding = Encoding.UTF8（7-Zip 21+ 默认 UTF-8，老版本需加-scsUTF-8参数）
真正麻烦的从来不是“怎么调”，而是“怎么知道它没 silently fail”。日志里没报错，但生成的 .7z 打不开——八成是参数拼错、路径没引号，或者 7z.exe 根本没执行成功。
