indexable-inc/blaze

如果你的日常是在中大型 Rust 项目里反复改一个函数再运行，并且能接受把工具链固定在某个具体版本，ra-jit 值得用一次。它不是 cargo 的通用替代品。

解决什么问题

现在的循环是：改一个函数，运行 cargo build 或 cargo run，等 rustc 重新链接，再想办法回到刚才测试的那个状态。对一个启动慢、需要一步步操作到某个界面的程序来说，回到原状态往往比改代码还费时间。ra-jit 改的是编辑之后那一步：第一次构建仍由 cargo 完成，等后台 daemon 把 workspace 加载并检查完，之后再执行 cargo ra-jit build 就只编译改动过的函数，并把它们写进 cargo 已经构建好的程序里。原本要重新链接的构建，现在几毫秒就结束。

有什么不同

ra-jit 用 rust-analyzer（多数 Rust 编辑器插件背后的引擎）把项目持续解析、类型检查在内存里，用 Cranelift 直接生成机器码，而不是每次重建都调用 rustc。编辑后它只修补发生变化的函数，而不是从头链接，后者正是增量构建耗时的主要部分。第一次构建由 cargo 完成，ra-jit 的代码链接到 cargo 的产物上。

更有意思的是 ra-jit-live 这个 crate：程序只要在主循环里加一个 poll，就能在运行中接收新的函数实现并保留状态，这对游戏、GUI 和任何需要反复回到特定界面的程序都很实用。代价也是结构性的：后台 daemon 对小项目就要占用几 GB 内存，对最大的项目可达几十 GB；而且并非所有编辑都走 ra-jit，部分改动仍会退回 cargo。用 ra-jit enable 让全局普通 cargo build 也走 ra-jit 时，项目文档明确说这比 cargo ra-jit 慢，在部分项目上甚至比普通 cargo 还慢，所以它不是给编辑器和 agent 白捡的便利。

按 README 给出的作者自测数据，在 ripgrep、nushell、helix、bun 上相对增量 cargo build 的平均加速分别是 macOS arm64 10×、Linux aarch64 24×、Linux x86-64 12×。这是作者自己的基准，不是独立测量；在期待自己的代码库也达到标题数字之前，值得先看完整的逐项目数据。

谁值得试

适合：在 Apple 芯片 macOS 或 Linux x86-64/ARM64 上，用固定工具链长时间编辑大型 Rust 代码库的开发者，尤其是那种需要反复运行程序并走到某个特定状态的人，并且愿意给程序加上 ra-jit-live。不适合：Windows 用户、Intel Mac 用户，或者项目必须跟随 stable Rust、会频繁切工具链的团队，因为 ra-jit 只支持 Rust 1.99.0 和 rust-src，其他版本一律静默退回普通 cargo。CI 也难从中获益，因为加速的是本地编辑循环，而不是构建流水线。

使用条件与边界

硬性条件包括带 rust-src 组件的 Rust 1.99.0、受支持的平台，以及给 daemon 留够内存；项目本身也必须能用 1.99.0 构建。安装后的四个可执行文件需要放在同一目录（~/.cargo/bin）里。目前还没有预编译二进制，所以用 crates.io 或 Nix 安装都要从源码编译，需要几分钟；cargo binstall 要等第一次二进制发布。装好之后，首次构建和 daemon 加载 workspace 仍按 cargo 的速度进行，收益要等一小段时间才出现，只有 cargo ra-jit status 会告诉你它是否就绪。

这些边界决定了要不要在项目里长期用它。部分改动会按设计交给 cargo，类型错误会像在 cargo 下一样失败，借用检查器的行为和平时一致。安装方式上，用 cargo 安装配合 rust-toolchain.toml 里写 channel = "1.99.0"，可以只让一个仓库进入这套流程，而不是全局切换工具链。此外 ra-jit 本身没有 watch 模式，需要配合 watchexec 这类文件监视工具实现保存即重建。

HotRepo 点评

HotRepo 最早的记录是 2026-10-25：仓库总计 293 stars，在 Rust 新项目榜排到 #16，距离开始追踪只有一天；可比较的每日榜单历史还不够，无法判断热度能否持续。这只是一个早期关注的快照，不是势头的证明。决定采用前，最该核对的是逐项目基准表，以及你的项目能否固定到 1.99.0 并装上 rust-src，因为版本锁定才是最关键的一道门槛。

项目源码与说明