增量编译快92倍：Blaze为何敢直接替代cargo？

命令行伪装成cargo：Blaze的极简入口

README 首页三行自我介绍：'Rebuild Rust in milliseconds. The same commands as cargo, with blaze in front. Blazingly fast Rust, literally.' 来源：GitHub 安装一行 curl 管道 sh，首次构建下载约 100 到 135 MB 的 Rust 工具链，已有 rustup 版本则直接复用 来源：GitHub。

对外只暴露 blaze run、blaze test、blaze build 三个命令，对应 cargo 同名子命令，其余直接透传 来源：GitHub。但 README 写了：'The first build runs cargo, then waits a few seconds for blaze to load your project.' 第一次构建仍走 cargo，Blaze 后台加载项目结构。改完一个函数再 build，才进入毫秒级区间，Finished 行显示 [ra-jit] 标识。

仓库体量与工程痕迹：一个已跑到2087次提交的项目

GitHub 显示 2,087 Commits 来源：GitHub，Blaze 不是周末项目。顶层同时出现 crates/、vendor/、harness/、pgo/、nix/、agents/ 六个子目录 来源：GitHub。pgo/ 是 profile-guided optimization 标准命名，harness/ 通常是回归测试套件，vendor/ 暗示内嵌第三方依赖。结构相当完整。

CLAUDE.md、AGENTS.md、.claude/ 和 agents/ 四个文件共存更耐人寻味 来源：GitHub。一个构建工具仓库同时维护 Claude 和通用 Agent 配置，说明它正在用 LLM 辅助开发自身。在 2087 次提交里看到这些文件已经常态化，而非尝鲜。docs/、site/、demo/、harness/ 四个非代码子目录说明有对外文档站与回归测试套件。

仓库同时挂 LICENSE-MIT 和 LICENSE-APACHE 双许可证 来源：GitHub，是 Rust 生态标准做法。配置层面走 Nix 与原生 Cargo 双轨：flake.nix、flake.lock 与 Cargo.toml、Cargo.lock、clippy.toml、rustfmt.toml 并存。

92x这个数字的含金量：多源交叉验证

92x 只出现在仓库标题里 来源：GitHub。README 正文的 How fast 章节给出的另一组数据：macOS arm64 上 10x、Linux aarch64 上 24x、Linux x86-64 上 11x，都是 'on average over real projects' 来源：GitHub。标题的 92x 与正文的 10 到 24x 之间差了四到九倍，这个分歧我没有找到解释。

HN 讨论页显示 Points: 2、Comments: 0 来源：HN。一个能宣称比 cargo 快 92 倍的项目，在 Hacker News 上只拿到 2 分 0 评论。92x 目前尚未经过社区复现或质疑。

README 把 How fast、How it works、Docs 作为独立锚点，暗示完整基准在 docs/ 下，但公开抓取到的片段没有展开。作者没有点名 rust-analyzer、sccache、Turbofish 等其他增量或缓存工具做对照，基准只选了 cargo/rustc。这个对照组选择偏保守。

另一个细节印证了 Blaze 的边界。既然号称快 92 倍，为什么首次构建还 'runs cargo'？说明它对全量冷启动并无优势，速度只兑现在增量场景。'About 20 ms from saving a file to a running program using the new code, with live edits' 来源：GitHub 是它给出的最有底气的数字，但前提是编辑器集成的热编辑。纯命令行冷启动场景，我不确定它能比 cargo 快多少。

原文：

Incremental rust builds up to 92x faster than cargo/rustc · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月27日