xevrion/hatchzip

解决什么问题

解压大压缩包时，传统工具要求压缩包和它解出来的文件同时存在，一个 180 GB 的下载包解开后 200 GB，就至少要 380 GB 空闲空间，笔记本、Steam Deck 或小容量 VPS 经常卡在这里。HatchZip 从压缩包尾部开始读取，每解出一批文件就把压缩包对应的一段切掉，让压缩包随着输出增长而缩小，从而只需为输出预留空间。

有什么不同

unzip、7-Zip、WinRAR 都把源压缩包当成只读文件，逐条写到新空间里，所以需要完整的双倍占用。HatchZip 的做法本质上是破坏性的，压缩包占用的块被直接让给输出。在核心思路之外，它多了三点：check 子命令在动任何东西之前精确算出需要多少空间；崩溃或中途停止后能续跑，不会留下坏输出；对 7z 的 solid 块有认知，当一整块无法提前释放时会明确拒绝，而不是写到一半失败。代价是压缩包解完就没了（除非显式选择保留），且 solid 压缩包仍可能要求可观的额外余量。

适合谁

适合在快满的磁盘上解压大型游戏包、数据集或备份的人：Steam Deck 和笔记本用户、小容量 homelab 与 VPS 运维、那些需要先删东西才能腾出空间的人。不适合三类人：必须保留原始压缩包的（请用保留模式或普通工具）；压缩包是 solid 7z 且块数少、空间又紧张的情况；以及在受管 Windows/macOS 环境里要求安装包已签名的团队。如果你要的是经过长期审计的压缩库而非命令行/GUI 工具，应继续使用 7-Zip 或 libarchive 生态。

上手成本

官方发布 Windows、macOS、Linux 安装包，也上了 Homebrew、Scoop、AUR 和 crates.io（cargo install hatchzip）；RAR 支持是编译期特性，会引入 UnRAR 的 C++ 源码并适用其自身许可证。引擎本身也以 hatchzip-core 库的形式发布。风险在于：Windows 和 macOS 安装包尚未代码签名，用户得手动绕过 SmartScreen 或 Gatekeeper；项目只有几天大、单一维护者、没有长期记录；崩溃恢复与打洞节省空间的效果依赖文件系统（ext4/XFS/btrfs 已验证，NTFS/APFS 仅声称未验证）。节省幅度与格式和布局强相关，README 里也明确记录了 solid 块被拒绝的场景。

点评

这个想法确实有用而且定位很窄：就地解压正是应对真实且常见的磁盘不足的正确思路。势头很猛但非常年轻——三天左右 1,644 星、新项目榜第 6，这只是脉冲而非履历，Hacker News 上那个极小的讨论帖也更像好奇而非采用。README 里的工程信号（逐字节输出比对、崩溃测试、构建来源签名）比多数三天大的项目扎实，但对一个默认破坏性操作的工具，在独立用户拿自己的压缩包跑过之前都应保持怀疑。今天值得在临时磁盘上跑一次 check，但要用它处理唯一一份数据，建议先等几个版本。