ZeroBrew：把 uv 的成功学搬到 macOS 包管理，但它现在已经停止维护

Homebrew 慢是 macOS 开发者的集体痛点——装一次包、升级一次库，那个 Ruby 脚本磨磨蹭蹭。ZeroBrew 想做的，就是把 Python 生态里 uv 秒杀 pip 的故事，复刻到 macOS 包管理：用 Rust 重写一个客户端，复用 Homebrew 的全部包资源，但速度快一个量级。本文基于其 README 分析它的提速真相，以及一个绕不开的现实——它已经停止维护。

一、背景：uv 故事的迁移

uv 用 Rust 重写 Python 包管理器，靠内容寻址存储与硬链接/克隆把依赖安装快了几十倍，几乎一夜之间成为事实标准。ZeroBrew 的逻辑如出一辙：Homebrew 慢主要慢在 Ruby 脚本的冷启动与文件拷贝，而不是包本身有多大。那就保留 Homebrew 的包定义与预编译包（bottle），只把慢的存储与调度层换成 Rust。

二、它是什么：Homebrew 的性能优化客户端

README 把自己定位得很清醒：“more of a performance-optimized client for the Homebrew ecosystem”。它不重新发明包，而是直接复用：

• Homebrew 的 formula 定义（homebrew-core）；
• Homebrew 的预编译 bottles（CDN）；
• Homebrew 的包元数据与基础设施。

它自己的创新集中在三处：

1. **内容寻址存储（content-addressable storage）**做去重；
2. APFS clonefile实现零开销拷贝；
3. 没有预编译包时，用 Homebrew 的 Ruby DSL 回退到源码编译。

命令几乎与 brew 对齐：zb install jq、zb bundle、zb outdated、zb upgrade、zb gc，甚至提供 zbx 不带链接直接运行。双协议开源（Apache-2.0 OR MIT，任选），Rust 占 89.6%。

三、关键数据：性能到底快多少

README 给的性能表（已核实原文）必须细看，因为”提速 20 倍”是标题党：

几个要点：

• Koala 标题里的”20 倍”，对应的是单个包热更新的最佳成绩（tesseract 29.5×、libsodium/sqlite 18.1×），而不是整体；
• 整体 Top 100 冷启动其实只有 2.0 倍，热更新 7.6 倍；
• 冷启动时 ffmpeg 反而比 Homebrew 慢（0.9×）——说明提速并不均匀，大而复杂的包冷启动并无优势；
• 真正拉开差距的是”热更新”（store 已有缓存时的克隆拷贝），这正是 APFS clonefile 发挥作用的地方。

四、最硬的局限：它已经停止维护

这是本文必须放在最显眼位置的事实。README 顶部用 Warning 框写着：

zerobrew is currently unmaintained.（ZeroBrew 当前未维护。）

并留了联系邮箱处理 CVE 等关键安全问题。这意味着：

1. 不要把它当作日常主力包管理器——没有后续维护，bug 与兼容性问题不会被持续修复；
2. README 自己也建议”与 Homebrew 并行运行，而非替换”，更明确警告”除非你完全清楚后果，否则不要删掉 Homebrew 用 zerobrew 替代”；
3. 它仍是 v0.3.2、experimental 状态，44 个开放 Issue、仅 4 个 PR。

五、官方未明说的局限与口径偏差

1. “兼容 brew”是客户端层兼容，不是 100% 等价：Koala 也提醒，Homebrew 的生态粘性不只在速度，复杂编译依赖、keg-only 包、链接路径这些才是硬仗——ZeroBrew 仍在追赶；
2. 提速靠存储层，不是协议革新：它复用 Homebrew 的 bottle CDN 与 Ruby DSL，没有独立的分发网络；
3. 冷启动优势有限：大包冷启动甚至更慢，“快 20 倍”是热更新单点峰值；
4. 跨平台：官网 zerobrew.rs 称支持 Linux，但 APFS clonefile 是 macOS 特性，Linux 上的提速机制与数字不能直接套用；
5. 未维护状态下，安全与兼容风险由使用者自担。

六、适用 / 不适用场景

适合：

• 想体验”Rust 包管理器 + 内容寻址存储”架构、愿意跑在 Homebrew 旁边做实验的开发者；
• 对热更新速度敏感、愿意接受实验软件风险的人。

不适合：

• 想用它替代 Homebrew 作为生产/日常主力（已停止维护，不要）；
• 依赖复杂编译、keg-only 包、需要稳定链接行为的环境；
• Linux 用户（APFS 特性失效，优势打折）。

七、客观分析：优势与局限

优势：

1. 架构思路正确：复用 Homebrew 资源 + 内容寻址存储 + clonefile，是经过 uv 验证的路线；
2. 热更新提速显著（18–29 倍）；
3. 命令兼容、迁移成本低；
4. 双协议开源，Rust 实现质量不错。

局限：

1. 已停止维护——这是致命项；
2. 整体冷启动只快 2 倍，个别大包反而更慢；
3. 复杂编译与 keg-only 生态仍是硬仗；
4. 实验状态，不建议替换主力。

八、它意味着什么

ZeroBrew 是一个”思路对、但命途短”的样本。它证明了把 uv 的内容寻址存储 + clonefile 搬到 Homebrew 确实能在热更新上拿到数量级提速；但它也诚实地标注了自己”未维护”，给所有想”重写 Homebrew”的人浇了一盆冷水：包管理的难点从来不是写一个快的 Rust 客户端，而是守住 Homebrew 那套复杂的编译依赖、keg-only 语义与生态兼容性。对普通用户，看看它的架构就好，日常还是老实用 Homebrew；对做包管理的工程师，它是一份值得研读的参考实现——尤其那个”热更新快、冷启动平庸”的性能表，把存储层优化的收益边界讲得很清楚。

参考来源

• lucasgelfond/zerobrew GitHub 仓库
• Koala 项目库条目