写过 Rust 的人都踩过这个坑——配了大半年项目，每次改一行代码都要等半天编译，明明 CPU 有 16 核但 rustc 只用了一个。今天这件事终于要变了。

写过 Rust 的人都踩过这个坑——配了大半年项目，每次改一行代码都要等半天编译，明明 CPU 有 16 核但 rustc 只用了一个。今天这件事终于要变了。

Rust 编译器团队 2024 年把「并行前端」列为旗舰目标之一，承诺让编译速度提升 20%。这个数字听起来不算惊人，但如果你手上的项目要编译 5 分钟，20% 就是整整省出 1 分钟——一天改十次代码，就省出 10 分钟。积攒起来是很可观的。

为什么 rustc 一直只用单核

这要先弄清楚 rustc 内部是怎么跑编译的。

rustc 的编译管线分几个阶段：词法分析/解析、宏展开、HIR 生成、类型检查、借用检查、MIR 优化、LLVM 代码生成。这么多年下来，rustc 的前端（词法、解析、宏展开）一直是串行跑的，只有后端的代码生成默认开了并行（-C codegen-units=N）。

原因不是团队不想并行，而是前端的几个阶段之间有复杂的依赖关系：类型检查依赖解析结果，借用检查又依赖类型检查结果，这些query依赖链要并行化需要重新设计整个调度系统。Rust 团队花了几年时间重写 query 系统，就是为了给并行化打基础。

2024 年 Rust 官方把「并行前端」列为 flagship goal，负责人 Sparrow Li 牵头推进，目标是把类型检查、借用检查和 MIR 优化这三块并行化。

怎么用、现在什么状态

并行前端目前在 nightly 版本可用，启用方式是加一个编译参数：

RUSTFLAGS="-Z threads=8" cargo build

threads 参数控制用几个线程跑前端。如果不设，默认用机器的全部 CPU 核心。

实测效果因项目而异，官方给出的预期是平均提速 20%。依赖越多、代码量越大的项目收益越明显；简单项目或者 CPU 核心数少的机器，收益会打折扣。

需要注意的是：并行化只覆盖前端三块（类型检查 + 借用检查 + MIR 优化），词法/解析/宏展开仍然是串行的。这三块在前端里耗时占比最大，但并不是全部。

什么时候能 stable？按 Rust 的发布周期，并行前端预计在 2025 年的某个版本稳定化——具体要看 2024 年内的推进进度。在此之前，所有数据和 API 都可能变，不建议在生产 CI 里用。

对前端工程师意味着什么

如果你用 Rust 写 CLI 工具、WebAssembly、或者用 wasm-pack 打包前端依赖，编译速度直接影响开发体验。每次改完代码等 cargo build 跑完，那种「这编译速度真的忍不了」的感觉会大幅缓解。

如果你用的是 wasm-pack build --target web，并行前端的效果同样适用——虽然 wasm-pack 本身有额外的 wasm-opt 步骤，但 rustc 并行化管的是前半段，同样能省时间。

怎么现在就试

如果你想现在就感受一下，先装 nightly 工具链：

rustup toolchain install nightly
rustup default nightly

然后用 cargo build 之前加 RUSTFLAGS：

RUSTFLAGS="-Z threads=0" cargo build

threads=0 表示用所有核心。观察一下编译速度有没有提升。

如果你的机器 CPU 核心数很多（12 核以上），可以试试不同线程数找到最优值：

RUSTFLAGS="-Z threads=16" cargo build

并行前端对齐后的 rustc 前途无量——未来还有 RustC v2 的规划，用纯 Rust 重写编译器前端，预计在 2026-2027 年带来 2-3 倍的编译提速。20% 只是第一步。