System.IO.Compression 无法直接生成自解压 EXE，需手动实现资源嵌入+运行时解压；主流做法是将 ZIP 设为嵌入资源，编写精简解压程序读取并解压到临时路径，再启动主程序。
用 System.IO.Compression 无法生成自解压 EXE
直接用 ZipFile.CreateFromDirectory 或 ZipArchive 只能生成 .zip 文件，不是可执行程序。C# 标准库不提供“把 ZIP 打包进 EXE 并附带解压逻辑”的能力——这本质是“资源嵌入 + 运行时提取 + 调用解压”的组合操作，得自己拼。
主流做法：嵌入 ZIP 资源 + 编译一个精简解压器
核心思路是写一个极小的 C# 控制台程序（比如 20 行），它启动后：① 从自身程序集的嵌入资源中读出 ZIP 数据；② 解压到指定路径；③ 可选地启动其中某个主程序（如 app.exe）。再把目标 ZIP 文件作为 Embedded Resource 加进这个项目，最后编译成 EXE。
实操要点：
- 在项目属性 → “资源”页签中，把你的
assets.zip拖入，设置其“生成操作”为Embedded Resource - 解压逻辑优先用
System.IO.Compression.ZipFile.ExtractToDirectory（.NET Core 2.0+ / .NET 5+），它比手动读ZipArchive更稳 - 避免用
Assembly.GetExecutingAssembly().GetManifestResourceNames()猜资源名——直接查项目生成的资源命名规则，通常是默认命名空间.文件夹.文件名，例如MySfx.Resources.assets.zip - 解压目标路径建议用
Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString("N"))，防止多开冲突
命令行打包自动化：用 dotnet publish + 资源注入
手动维护资源容易出错，更可靠的方式是构建时注入 ZIP。可用 MSBuild 的 BeforeCompile 目标，在编译前把 ZIP 复制为资源文件并更新 .csproj 中的 <embeddedresource></embeddedresource> 条目；或者更简单：用 PowerShell / Bash 先编译空壳程序，再用 ResHacker 或 rcedit（需适配 Windows PE）把 ZIP 作为自定义资源段追加进去——但这种方式需要额外解析 PE 结构，调试成本高，仅适合有 PE 操作经验的人。
对多数人，推荐折中方案：
- 写好解压主程序（
Program.cs），确保它能从资源加载 ZIP 并解压 - 用
dotnet publish -c Release -r win-x64 --self-contained true发布为独立 EXE - 用
7z a -sfx（7-Zip SFX 模块）把发布后的 EXE 和 ZIP 合并——注意：这不是 C# 原生方案，但最稳定、兼容性最好，且支持静默解压参数（如-y -o"C:\target"）
真正要注意的坑：权限、路径和防误删
生成的自解压程序常被杀软拦截（尤其当它释放 EXE 并尝试启动），也容易因 UAC 或目标目录无写入权而失败。实际部署时必须考虑：
- 解压前检查目标路径是否可写，用
Directory.GetAccessControl(path).GetAccessRules(true, true, typeof(System.Security.Principal.SecurityIdentifier))太重，简单用try { File.WriteAllText(Path.Combine(target, "test.tmp"), "x"); File.Delete(...); }更快 - 不要默认解压到
Program Files，优先选Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) - 如果解压后要运行子进程，别直接
Process.Start("app.exe")，加上UseShellExecute = false和完整路径，否则在某些系统上会找不到工作目录 - 资源 ZIP 如果超过 100MB，嵌入后会导致 EXE 启动变慢（因为整个资源要加载进内存），此时应改用“下载后解压”或分卷资源策略
嵌入 ZIP 是最轻量的自解压实现方式，但“轻量”不等于“无感”——资源加载、临时路径清理、异常静默失败，这些细节不处理好，用户点开就卡住或无声退出，问题反而更难定位。
