下游戏最崩溃的一刻不是下载慢，是下载完了解不开。一个 180GB 的压缩包，解开是 200GB，进度条爬到一半弹出「磁盘空间不足」。
你明明还有 200 多 GB 的空闲，却不给你解。因为常规解压工具要求压缩包和解压出来的文件同时在盘上待着，加起来得 380GB。包越大，这个浪费越离谱。
GitHub 上 10 月 21 日上线的一个工具专治这件事。它叫 HatchZip，纯 Rust 写的开源解压器，到 10 月 28 日攒了 2233 颗星、69 次派生，8 个版本的安装包被下载了 15213 次。
解压同一批数据所需的磁盘空间
它的做法是把压缩包倒过来用：从包的末尾开始解压，解完一段就把这一段从原文件里切掉，腾出来的空间立刻给下一段用。
所以整个过程里，磁盘上不会同时存在「完整的包」和「全部的文件」。那个 180GB 的包，它只比 200GB 多要一点点，剩下的 180GB 全省了。
五种压缩包的实测结果
要看清的第一件事：它省的是「峰值空间」，不是让文件凭空变小。
解压完成后你该占多少还是多少。它多要的那一点空间，约等于它能一次性释放的最大单元——ZIP 和 tar 是一个文件，7z 是一个固实块。7z 用默认设置压出来的单个固实块，它会在动手之前直接拒绝，告诉你这个包得先有 200MB 空闲，绝不会解到一半崩掉。
要看清的第二件事：顺手还更快了。
同一批 21 个文件、200MB 的数据，ZIP 解压它用了 0.25 到 0.35 秒，unzip 6.00 用了 1.48 到 1.50 秒——而它还多做了一次 unzip 跳过的刷盘操作。快的原因是把多个文件并行解压，所以如果一个包里只有一个巨大文件，那就还是单核的速度，快不起来。
要看清的第三件事：有两个坎得提前知道。
一是它要求文件系统支持「把文件收缩」，ext4、btrfs、XFS、NTFS、APFS 都行，exFAT 和 FAT32 的 U 盘也可以，这点比想象中宽松。二是它还没做代码签名，Windows 安装时会弹「Windows 已保护你的电脑」，要点「更多信息」再选「仍要运行」。
另外，作者在开发说明里专门点名：只有仓库的发布页和它自己的官网是官方渠道，其余同名的网站都和这个项目没有关系。
上线七天时间线
它读 ZIP、7z、tar、.tar.gz、RAR 分卷和拆分压缩包，有桌面版也有命令行，Windows 10/11、macOS、Linux 三端都有安装包。装完不用管，右键点压缩包选它就行，Windows 11 藏在「显示更多选项」里。
中途关掉、断电、崩了都不怕，它会从断点接着来。作者拿每种格式在批次的两个危险时刻反复杀进程，每一次续解的结果都和完整解压逐字节一致。
你最近一次因为磁盘不够解不开包，是什么时候？