Rust写大型项目时，编译太慢怎么办？

如果你用过 Rust 写过稍微大一点的项目，大概都有过这种经历------改了一行代码，泡了杯咖啡回来，进度条还没走完。这不是个别现象，而是整个 Rust 社区多年来的集体心病。本报告综合官方调研数据、社区真实案例与一线实践经验，试图把这个问题说清楚，也给出能真正落地的应对思路。 $3$

编译为什么这么慢？从根子上说

Rust 的慢，不是工程师偷懒造成的，而是语言本身做了一笔"用编译时间换运行时安全"的交易，代价就由开发者每天买单。

语言设计埋下的伏笔

单态化（Monomorphization） 是最大的幕后推手。泛型代码在编译期会为每一种具体类型各生成一份实现，代码体积膨胀，编译器的工作量也随之翻倍。借用检查器（Borrow Checker）则需要做全程序级别的生命周期推导，计算量相当可观。

过程宏（proc macro）是另一个隐形杀手。serde、tokio、diesel 这些库背后都依赖大量 derive 宏，而每个过程宏在编译期都是一个独立进程，开销远比看起来要高。再加上 Rust 默认使用 LLVM 做代码生成------LLVM 的优化质量毋庸置疑，但速度从来不是它的强项。 $3$

项目结构放大了问题

语言层面的成本是固定的，但项目结构会把问题放大好几倍。单一的巨型 crate 让编译器无法并行处理，增量编译引擎在跨 crate 边界时也会部分失效。CI 环境如果没有缓存配置，每次 PR 都是一次从零开始的全量构建，时间成本直接叠加到团队的交付节奏上。 $4$

官方数据说了什么

Rust 编译器性能工作组在 2025 年发布了一份专项调查报告，收集了大量真实开发者的反馈，几个核心发现相当直白： $2$

痛点类别	开发者的真实感受
增量重建太慢	改一行代码，等待时间和全量构建差不多
Clean Build 时间过长	大型项目首次构建动辄 10 分钟起步
CI 无缓存	每次 PR 全量重建，流水线严重拖速
proc macro 拖累全局	引入重宏库后编译时间近乎翻倍
跨平台编译更惨	x64 Linux 以外的平台优化投入明显不足

有一个数字值得记住：从 2022 年到 2025 年，rustc 在同一个真实项目（hyperqueue）上的 clean build 时间从 26.1 秒降到了 14.7 秒 ，提升接近 1.77 倍。进步是真实的，但对很多团队来说，还远远不够。 $3$

真实案例：别人踩过的坑

改一行代码，等一分钟

Rust 官方论坛上有一个帖子，开发者描述了一个中等规模项目里令人崩溃的日常：每次增量构建超过一分钟 。排查下来，问题出在三处：项目是单一巨型 crate，大量使用 serde 和 diesel 的 derive 宏，而且 debug 构建还在用 LLVM。切换到 Cranelift 之后，增量构建时间掉到了几秒钟。 $5$

sccache：有用，但别指望它包治百病

2025 年有篇博客记录了在大型 Rust 项目里用 sccache 的真实体验，结论相当务实：对依赖层的缓存命中效果不错，但 proc macro 和 build script 压根没法被缓存，这两块依然是瓶颈。换句话说，sccache 能帮你省掉重复构建依赖的时间，但救不了你自己写的业务代码。 $6$

游戏开发者的出走

知名博文《Leaving Rust Gamedev》被官方性能博客多次引用，描述了游戏开发场景下的困境：频繁的小改动需要秒级反馈，但 Rust 在游戏引擎规模下的增量编译仍需 30 秒到 2 分钟。热重载生态又不成熟，等待感被进一步放大。最终，部分开发者选择回到 C++ 或转向 Zig。 $3$

Reddit 上的社区共识

2025 年 Reddit 上一篇高热帖子《Rust's compile times make large projects unpleasant》汇聚了大量一线经验。社区的共识是：换用 mold 或 lld 链接器，再把单一大 crate 拆成 workspace 多 crate，增量构建速度能提升 3 到 5 倍。这两步操作成本低，收益却相当可观。 $4$

怎么解决？按性价比排个序

今天就能做的事

cargo check 替代 cargo build，做语法和类型检查时跳过代码生成，速度提升 3 到 10 倍，几乎零成本。

bash 复制代码

cargo check

换掉默认链接器 。mold 是目前 Linux 下最快的链接器，在大型项目里比默认的 ld 快 5 到 10 倍，改一行配置就能生效：

toml 复制代码

# .cargo/config.toml
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=mold"]

启用 sccache，对 CI 和共享构建服务器场景效果明显，依赖层的缓存命中率相当高： $6$

bash 复制代码

cargo install sccache
export RUSTC_WRAPPER=sccache

花点时间配置，收益更大

Debug 构建切换 Cranelift。Cranelift 是专为快速编译设计的代码生成后端，debug 模式下速度提升 2 到 3 倍，release 构建不受影响： $5$

toml 复制代码

[profile.dev]
codegen-backend = "cranelift"

把大 crate 拆成 workspace。这是结构性改造，但回报也是结构性的------让 Rust 的并行编译真正发挥作用：

perl 复制代码

my-project/
├── crates/
│   ├── core/
│   ├── api/
│   └── cli/
└── Cargo.toml

调整 profile 配置，让依赖库用 O2 优化、自己的代码用 O0，在编译速度和调试体验之间找到平衡： $1$

toml 复制代码

[profile.dev]
opt-level = 0
debug = 1
incremental = true

[profile.dev.package."*"]
opt-level = 2

进阶操作，适合认真优化的团队

cargo --timings 诊断瓶颈，生成可视化 HTML 报告，精确定位哪个 crate 在拖后腿：

bash 复制代码

cargo build --timings

减少 proc macro 依赖 。用 miniserde 替代 serde，或者对简单 trait 手动实现而非依赖 derive，能削减相当一部分编译开销。

实验性并行前端，在多核机器上有 1.5 到 2 倍的潜在提升：

bash 复制代码

RUSTFLAGS="-Z threads=8" cargo build

3

方案一览

方案	适用场景	预期提升	上手难度
`cargo check`	日常开发反馈	3~10x	⭐ 极低
`mold` 链接器	Linux 大型项目	5~10x（链接阶段）	⭐⭐ 低
`sccache` 缓存	CI / 共享服务器	依赖层 50~80%	⭐⭐ 低
Cranelift 后端	Debug 开发构建	2~3x	⭐⭐ 低
Workspace 拆分	大型单体项目	3~5x（增量）	⭐⭐⭐ 中
profile 优化	通用	10~30%	⭐⭐ 低
减少 proc macro	重宏依赖项目	20~50%	⭐⭐⭐⭐ 高
并行前端（实验）	多核机器	1.5~2x	⭐⭐⭐ 中

写在最后

Rust 编译慢，本质上是一种设计选择的代价------编译器替你承担了运行时本该出现的错误，这笔账总要有人付。好消息是，官方编译器性能工作组一直在认真还债：三年间真实项目的构建速度提升了近 2 倍，并行前端和新增量引擎也在推进中。 $2$ $3$

眼下最务实的态度，是把能做的优化先做了------换链接器、开缓存、用 cargo check，这三步几乎不需要任何代价，却能让日常开发体验好上一个台阶。至于更深层的结构性改造，等项目真正长大了再说也不迟。

参考来源：