解压大包还要双倍空间
下载一个 180 GB 的游戏安装包，解压后变成 200 GB，传统工具却要你预留 380 GB 磁盘——WinRAR、7‑Zip 或 unzip 都得把压缩包和解压结果同时放在盘里。这在只有 256 GB SSD 的笔记本上简直是噩梦。
传统工具的硬伤
常见解压器都是「先读整个压缩包，再写出所有文件」，磁盘占用 = 原包大小 + 解压后大小。README 里直白写着：「A 180 GB game download that unpacks to 200 GB needs 380 GB of disk with WinRAR, 7-Zip or `unzip`」。
反直觉思路：从尾部倒着解、边解边截
HatchZip 另辟蹊径：从压缩包尾部倒着解压，每解出一个文件就把已解部分从原文件里截掉。于是压缩包在解压过程中不断「瘦身」，磁盘只需容纳最终的输出体积。作者在 README 里强调：「Extract huge archives in place. The archive shrinks as your files hatch, so you only need free space for the output, not for the output *and* the archive.」
为什么选「截断」而不是「打洞」？作者在 10‑23 的技术帖里解释：FAT/exFAT 根本不支持打洞，只有截断在所有文件系统上都通用。流程如下：
- 读取中央目录定位最后一个文件入口
- 倒序解压该文件，写入目标路径
- 对解出数据做 CRC‑32 校验，校验通过后再
truncate压缩包文件 - 在日志里记录已完成偏移，下次启动直接续传
这种「解一个、截一个」的设计，让磁盘峰值占用永远等于已解出文件的总大小，理论上只比最终体积略大。
CRC 校验与断点续传
每个文件解压完成都要通过 CRC 校验才会触发截断，避免写坏数据导致包损坏。日志文件记录已处理的字节偏移，断电或杀进程后再跑 hatchzip extract game.zip 会自动从上次位置继续，不必重头开始。
比 unzip 快约 5 倍，格式支持一览
官方声称支持「ZIP, 7z, tar, `.tar.gz` and split archives」。实测对比显示：hatchzip 解压同一 180 GB 包仅需 0.25‑0.35 s，而 unzip 6.00 要 1.48‑1.50 s，快约 5 倍。速度优势来自避免了全量读写和额外的临时文件创建。
- ZIP / split ZIP：完美支持
- tar / .tar.gz：流式解压，同样边解边截
- 7z（非 solid）：可用，但见下文限制
solid 7z 会被直接拒绝
作者明确标注：「7z from 7-Zip with default settings (1 solid block)」会被「Refused before touching anything」。因为 solid 压缩把所有文件合成单一数据块，无法从尾部单独提取单个文件，HatchZip 直接拒绝处理，避免产生损坏输出。
上手命令速查
hatchzip check game.zip—— 仅校验完整性，不写磁盘hatchzip extract game.zip—— 原地解压，边解边截hatchzip restore game.zip—— 从日志恢复被截断的原包（实验性）hatchzip test game.7z—— 测试 7z 非 solid 包能否处理
作者自述与专利背景
仓库创建于 2026‑10‑21，采用 Apache‑2.0 许可，Rust 编写。作者在 技术讨论帖 里坦言：「IBM has a patent (US 8275750)」 —— 思路并非首创，但开源落地且兼容主流文件系统，才是实用价值所在。本周在 OffHype 非 AI 榜 上也能看到它的热度上升。
