indexable-inc/ra-jit

如果你的瓶颈是 Rust 改一行等一次完整编译的时间，ra-jit 值得一试；但它只认一个 Rust 版本、内存占用也不小，适用范围比较窄。

解决什么问题

你改一个函数，跑 cargo build，然后等 rustc 重新链接整个程序才能看到结果。工作区一大，哪怕增量构建也慢到打断思路；而重启应用后回到原来的运行位置，往往比编译本身更费时间。ra-jit 把项目放在内存里保持解析和类型检查，只把变化的函数编译出来写进 cargo 已经生成的可执行文件，因此第二次构建能在毫秒级完成。选择接入 ra-jit-live 的程序还能在运行中直接换上新代码。

有什么不同

ra-jit 不是包住 rustc，而是和 cargo 并排工作。它借助 rust-analyzer 在内存里维护项目，用 Cranelift 生成机器码，改动后只编译变化的函数并写回现有程序，而不是重新走一遍链接。第一次构建仍然交给 cargo，ra-jit 的代码随后链接到它的产物上。作者给出的数据是：在 ripgrep、nushell、helix、bun 等项目上，平均比增量 cargo build 快 10 倍（macOS arm64）、24 倍（Linux aarch64）、12 倍（Linux x86-64）。

这种速度有明确的边界。ra-jit 只针对 Rust 1.99.0 及 rust-src 编译，项目只要锁定别的工具链，每次构建都会退回普通 cargo。也不是所有改动都走 ra-jit：部分编辑会交给 cargo，cargo ra-jit status 会把两种都计入。后台进程为小项目占几 GB，最大的项目要占几十 GB，这会影响你如何安排并行构建的机器。

谁值得试

适合在 Apple 芯片 Mac 或 Linux x86-64/ARM64 上迭代较大 Rust 代码库的人，尤其是长时间运行的游戏、GUI 或其他不易恢复状态的程序，这时 ra-jit-live 和运行中热替换才真正有价值。不适合 Windows 用户：ra-jit 能装上，但每次构建都交给 cargo；也不适合无法用 1.99.0 构建的项目，因为加速根本不会生效。如果你习惯让编辑器、脚本或 agent 直接跑 cargo build，ra-jit enable 会把整个用户下的普通 cargo 转到 ra-jit，但项目文档说明这样编辑会慢一些，某些项目甚至比普通 cargo 还慢。

使用条件与边界

需要 Rust 1.99.0 加 rust-src 组件，并且项目本身能用它构建。平台仅限 Apple 芯片 Mac、Linux x86-64 和 Linux ARM64，Intel Mac 不受支持。从 crates.io 安装要现场编译，需要几分钟；Nix 也走源码构建，暂无二进制缓存；官方还没有发布预编译包。安装后四个程序要一起留在 ~/.cargo/bin。日常开销是后台进程的几 GB 到几十 GB 内存，以及加载等待——小项目几秒，特别大的项目约一分钟，这段时间里的构建仍是 cargo 的。

HotRepo 点评

ra-jit 才创建 5 天。HotRepo 在 2026-10-25 的新项目榜（不是总榜）记录到 248 个总星数。现有历史缺少可比的每日榜单数据，无法判断热度能否持续。决定投入前，请先确认你的项目确实能用 Rust 1.99.0 加 rust-src 构建，并阅读安装说明：工具链不对时，每次构建都会悄悄退回 cargo。