开源工具圈最近最吸睛的数字，来自一个试图革 Homebrew 命的项目：Zerobrew 宣称自己是 100 倍提速 的替代品，要把 Python 生态里 uv 的架构经验搬到 macOS 和 Linux 的包管理中。
它的测试账面看起来极其震撼：在 100 个软件包的基准测试里，冷安装耗时从 Homebrew 7.0.8 的 775.60 秒缩短到 117.43 秒，热安装更是从 637.50 秒压到 9.33 秒。但撕开百倍光环的包装，这既不是一场平等的同台竞技，更不是可以安心替换系统的万灵药。
跑分测谎：星号背后的非对称测试
基准测试是在配备 M3 Pro 芯片、18GB 内存的 MacBook Pro 与 macOS 26.6.2 系统下测得的，网络带宽约为 318 Mbit/s。所谓的百倍提速，在标题里带有明确的星号，实际仅对应 100 个包中 24 个在热重装场景下的极端表现。比如 ca-certificates 测出了 252.12 倍提速（耗时从 6.55 秒降至 26 毫秒），node 测出了 121.72 倍提速（从 28.24 秒降至 232 毫秒）。
然而细看测试脚本就会发现，两者的热测试处于完全不对等的工况。Homebrew 的热安装测试保留的是已下载压缩归档，每次执行仍需从头解压归档并调用外部签名；Zerobrew 的热安装不仅留着下载缓存，还保留了已解压的内容寻址存储（CAS），它的热重装几乎只做了一次文件系统的硬链接操作。
拿单纯的硬链接耗时去对比解压加签名的全流程，量级差异在机制设计时就已经注定了。
测试环境本身也经过了高度定制：测试关闭了 Homebrew 的自动更新和自动清理，将配方索引加载排除在计时之外，且每个条件仅单次固定顺序执行，未做多次采样平均。一旦网络带宽从 318 Mbit/s 降到普通的 69 Mbit/s，面对 go 和 llvm 这类大体积制品，下载时间立刻成为瓶颈，Zerobrew 的冷安装提速倍数直接从 6.6 倍腰斩至 3.3 倍。
移植之困：虚拟环境经验遇到系统级复杂性
uv 之所以能在 Python 生态所向披靡，是因为 Python 虚拟环境高度封闭，丢弃旧环境并不影响全局运行环境。但系统级包管理面对的是动态库链接与复杂的全局语义。
Zerobrew 承认自己完全依赖 Homebrew 的构建农场、配方定义和预编译制品，其核心改动在于跳过 Ruby 运行环境，采用 Rust 在进程内完成二进制重定位，并通过 APFS clonefile 或硬链接来实现去重与极速分发。
这种激进的移植很快碰上了底层逻辑冲突。在 Homebrew 生态中，keg_only 属性是用来防止特定软件版本覆盖系统默认库的重要隔离机制，但在实际使用中，Zerobrew 的解析器直接忽略了这一隔离规则，导致本地运行环境面临污染风险。
类似的问题并不罕见：源码构建 openssl@3 时报出未定义方法的底层错误，Linux 环境下 ELF 二进制打补丁失败，并且完全不支持用于图形界面的 Cask。将用于独立沙箱的链接方案套在彼此强耦合的系统包上，速度上去了，稳定性却被撕开了口子。
安全与信任：吃官方制品不等于自带官方防线
在供应链层面，最大的认知误区莫过于误以为调用官方制品就天然安全。客户端本身就是安全边界的一部分，重写客户端意味着引入全新的攻击面。
该项目曾曝出 CVSS 评分为 7.5 的高危漏洞 CVE-2026-53970，影响 v0.3.1 及更早版本。其原因在于兼容垫片在源码编译时，没有对次级资源和补丁下载验证校验和，直接埋下了远程代码执行风险。该缺陷在 2026 年 6 月 12 日发布的 v0.3.2 中才被修复，直到 8 月份才完成公开披露。
与安全漏洞交织的，是工程实现上的信任赤字。在社区讨论中，作者承认架构设计由人工主导，但大量底层代码依赖大语言模型辅助编写。系统级工具需要对文件系统权限、内存安全和构建流程做极严苛的防御性校验，在缺乏独立第三方安全审计报告背书的情况下，过快堆叠代码往往意味着隐藏的技术债务。
虽然项目在 2026 年 5 月底的 v0.3.0 中补上了包升级命令，并在 10 月 8 日迭代至 v0.4.0，累计获得超过 7,600 颗 Star，但官方依然在文档中明确将其标记为实验性工具，并警告用户不要删除 Homebrew。
- 建议.在持续集成与快速构建临时容器中，Zerobrew 能够利用缓存大幅压缩等待时长，是极佳的性能加速器。
- 风险.由于忽略 keg_only 隔离且缺乏独立安全审计，切勿将其作为主力开发机的唯一包管理器，避免本地环境损坏或引入供应链隐患。