调查研究-201 Rust 里的 dev build 和 release build：为什么同一份代码性能差这么多？

TL;DR

场景：Rust 新手/服务端开发用 cargo run 或 target/debug 跑压测，看到 CPU 飙高、吞吐拉胯，误以为 Rust 性能不行。
结论：cargo build 默认走 dev profile（opt-level = 0），几乎不做优化；cargo build --release 走 release profile（opt-level = 3），同份代码常带来 2--200 倍性能差异，CPU 占用、p95/p99 都会显著下降。
产出：一份覆盖 dev/release 构建差异、性能差距量级、压测对比方法、生产 Cargo.toml 调优配置的实操指南。

版本矩阵

功能	状态	说明
`cargo build` 默认走 `dev profile`	✅ 已验证	`opt-level = 0`、保留 debuginfo、开启 `debug_assert!` 与溢出检查，输出至 `target/debug`（来源：The Cargo Book Profiles）
`cargo build --release` 默认走 `release profile`	✅ 已验证	`opt-level = 3`、关闭 `debug_assert!` 与溢出检查、关闭 debuginfo，输出至 `target/release`（来源：The Cargo Book Profiles）
release 相对 dev 性能提升 2--200 倍	⚠️ 待验证	经验范围，受代码类型、依赖、机器、I/O 比例影响，需基于自身业务压测
`release` 二进制在固定 QPS 下 CPU 下降	✅ 已验证	经验上 20%--80% CPU 下降很常见，但饱和压测时 CPU 仍可能 100%
`release` 二进制内存一定更省	❌ 不成立	CPU 通常显著改善，内存需实测；内联/循环展开可能让代码段略大
`debug_assert!` 在 release 下生效	❌ 不成立	release 默认不执行，生产校验必须用 `assert!` 或正常错误处理
`[profile.release]` 中 `lto/codegen-units/strip/panic` 可叠加优化	✅ 已验证	`lto = "thin"`、`codegen-units = 1`、`strip = true`、`panic = "abort"` 均为官方支持项（来源：The Cargo Book Profiles）

TL;DR

在 Rust 项目里，cargo build 和 cargo build --release 生成的不是"差不多的程序"。

它们使用的是两套不同的构建配置：

bash 复制代码

cargo build

默认使用 dev profile，适合开发、调试、快速编译。

bash 复制代码

cargo build --release

默认使用 release profile，适合部署、压测、生产运行。

最重要的区别是：dev build 基本不做性能优化，而 release build 会启用编译器优化。

所以，Rust 项目里不能用 target/debug 下的二进制判断最终性能。CPU 占用、吞吐、延迟、单请求处理成本，都应该以 target/release 下的二进制为准。

一句话总结：

开发用 cargo build，部署和压测用 cargo build --release。

1. 问题从哪里来？

很多人第一次写 Rust 服务时，会直接这样启动：

bash 复制代码

cargo run

或者：

bash 复制代码

cargo build
./target/debug/your_app

然后打开 top 一看：

bash 复制代码

top -p <pid>

发现 CPU 占用偏高。

这时很容易得出一个错误结论：

Rust 怎么 CPU 占用这么高？

但这里有一个关键前提：你运行的可能是 debug/dev 构建产物。

在 Rust 里，debug 构建不是为了性能准备的。它的目标是：

text 复制代码

编译快
调试方便
保留调试信息
开启更多检查
让开发阶段的问题更容易暴露

它不是为了低 CPU、低延迟、高吞吐准备的。

真正要看运行效率，应该使用：

bash 复制代码

cargo build --release
./target/release/your_app

或者：

bash 复制代码

cargo run --release

2. `cargo build` 到底做了什么？

执行：

bash 复制代码

cargo build

Cargo 会使用默认的 dev profile。

生成目录是：

bash 复制代码

target/debug/

典型特征是：

toml 复制代码

[profile.dev]
opt-level = 0
debug = true
debug-assertions = true
overflow-checks = true

这意味着：

text 复制代码

几乎不做优化
保留调试信息
开启 debug_assert!
整数溢出检查默认开启
编译速度快
运行速度慢

也就是说，cargo build 的重点不是生成最快的程序，而是尽快生成一个方便调试的程序。

这对开发很合理。你改了一行代码，希望马上编译、马上运行、马上定位问题。这个阶段不应该让编译器花大量时间做深度优化。

所以 dev build 的设计目标是开发效率，不是运行效率。

3. `cargo build --release` 到底做了什么？

执行：

bash 复制代码

cargo build --release

Cargo 会使用默认的 release profile。

生成目录是：

bash 复制代码

target/release/

典型特征是：

toml 复制代码

[profile.release]
opt-level = 3
debug = false
debug-assertions = false
overflow-checks = false

这意味着：

text 复制代码

开启高等级优化
默认不保留完整调试信息
关闭 debug_assert!
默认关闭整数溢出检查
编译速度慢
运行速度快

release 构建的目标是生产运行。

编译器会尽量优化代码，例如：

text 复制代码

函数内联
死代码消除
常量折叠
循环优化
更好的寄存器分配
泛型代码优化
跨函数优化
更积极的 LLVM 优化

所以同一份 Rust 代码，debug 版本和 release 版本的运行效率可能完全不是一个级别。

4. 性能一般能差多少？

没有一个固定倍数，因为差距取决于程序类型。

一般经验是：

场景	release 相比 dev 的常见提升
普通业务逻辑	2-10 倍
HTTP 服务	2-20 倍
JSON 解析、序列化、协议编解码	5-50 倍
CPU 密集计算	10-100 倍
图像、音频、压缩、加密	20-200 倍都有可能
I/O 密集程序	1.2-5 倍

这些数字不是承诺，只是经验范围。真正结果取决于你的代码、输入、机器、依赖、I/O 比例和压测方式。

如果程序主要卡在网络、磁盘、数据库上，release 的提升可能没那么夸张。

如果程序主要卡在 CPU 上，比如大量循环、文本处理、序列化、加密、压缩、音频处理、协议解析，那 release 的提升可能非常明显。

Rust 的 debug 构建性能经常会让人误判语言本身的速度。

所以不要用：

bash 复制代码

cargo run

来做性能测试。

要用：

bash 复制代码

cargo run --release

或者：

bash 复制代码

cargo build --release
./target/release/your_app

5. 为什么 dev build 会慢？

原因不是 Rust 慢，而是 dev build 故意没有充分优化。

5.1 函数内联少

很多小函数在 release 模式下会被内联。

例如：

rust 复制代码

fn add_one(x: i32) -> i32 {
    x + 1
}

fn main() {
    let mut sum = 0;
    for i in 0..1000000 {
        sum += add_one(i);
    }
    println!("{}", sum);
}

在 dev 模式下，函数调用可能真实存在。

在 release 模式下，编译器可能直接把 add_one(i) 优化成 i + 1，减少函数调用成本。

5.2 循环优化弱

release 模式会对循环做更多优化，例如：

text 复制代码

减少重复计算
移除无用分支
改善寄存器使用
尝试向量化
减少边界检查

dev 模式下，这些优化通常很弱。

5.3 边界检查更难被消除

Rust 对数组、切片访问会做边界检查。

rust 复制代码

let value = arr[i];

这本身是安全特性，不是问题。

但在 release 模式下，如果编译器能证明 i 一定合法，就可能消除部分边界检查。在 dev 模式下，这类优化较少，循环中的边界检查成本更明显。

5.4 整数溢出检查

debug/dev 模式下，整数溢出通常会触发 panic。

rust 复制代码

fn main() {
    let x: u8 = 255;
    let y = x + 1;
    println!("{}", y);
}

dev 模式下可能直接 panic。

release 模式下默认会按溢出回绕处理，u8 的结果可能变成 0。

这说明两种模式不只是性能不同，某些运行行为也可能不同。

5.5 `debug_assert!` 行为不同

rust 复制代码

fn main() {
    let x = 1;
    debug_assert!(x == 2);
    println!("done");
}

dev 模式下，debug_assert! 会执行。

release 模式下，默认不会执行。

所以不要把核心业务校验写进 debug_assert!。

如果是必须在生产环境生效的检查，应该使用：

rust 复制代码

assert!(condition);

或者正常错误处理逻辑。

6. CPU 占用会不会因为 release 下降？

通常会。

如果代码不变、请求量不变、工作量不变，从 dev 切到 release 后，CPU 占用大概率下降。

例如同样每秒处理 100 个请求：

text 复制代码

dev build:     CPU 80%
release build: CPU 15%-40%

这类现象很常见。原因很简单：release 版本单次请求的执行成本更低。

但是要区分两种场景。

第一种是固定负载。

假设服务固定每秒处理 100 个请求。如果 dev 模式 CPU 是 80%，release 模式可能降到 20%。这种情况下，CPU 百分比下降是正常优化结果。

第二种是压测打满。

假设你用压测工具一直把服务打满：

bash 复制代码

wrk -t4 -c100 -d60s http://127.0.0.1:8080/

这时 release 模式下 CPU 可能仍然是 100%。

但这不代表 release 没有优化。

可能是因为 release 版本吞吐更高，能处理更多请求，所以压测工具继续把 CPU 打满。

这时不能只看 top 里的 CPU 百分比。

应该同时看：

text 复制代码

QPS 是否上升
p50 是否下降
p95 是否下降
p99 是否下降
单请求 CPU 成本是否下降
同等 QPS 下 CPU 是否下降

压测时，CPU 100% 不一定是坏事。

如果 CPU 100%，但 QPS 提升了很多，延迟还下降了，那 release 的优化就是有效的。

7. 内存占用会不会因为 release 下降？

不一定。

CPU 方面，release 大概率明显改善。

内存方面，情况更复杂。

release 可能降低内存占用，因为：

text 复制代码

临时对象更少
无用代码被消除
栈使用更合理
某些分配被优化掉

但 release 也可能让部分内存看起来差不多，甚至略高，因为：

text 复制代码

函数内联可能增加代码段体积
循环展开可能增加机器码体积
优化后的二进制不一定更小
debug 信息主要影响磁盘上的二进制体积，不一定全部进入常驻内存

所以内存不能简单判断为：

text 复制代码

release 一定比 dev 省内存

更准确的结论是：

text 复制代码

release 通常显著降低 CPU 成本，但内存变化需要实测。

如果想减小 release 二进制体积，可以在 Cargo.toml 中配置：

toml 复制代码

[profile.release]
strip = true
panic = "abort"
lto = "thin"
codegen-units = 1

但这些配置也有代价，例如编译变慢、调试难度增加、panic 栈信息减少。

8. 空闲 CPU 也高，release 不一定能救

这是非常重要的一点。

如果程序在没有请求、没有任务、没有压测时，CPU 仍然很高，那通常不是构建模式问题，而是代码逻辑问题。

常见原因包括：

8.1 死循环没有 sleep

rust 复制代码

loop {
    check_status();
}

这种循环会一直占用 CPU。应该至少加入等待：

rust 复制代码

loop {
    check_status();
    tokio::time::sleep(std::time::Duration::from_millis(100)).await;
}

8.2 channel 接收失败后立刻重试

rust 复制代码

loop {
    match receiver.try_recv() {
        Ok(msg) => handle(msg),
        Err(_) => continue,
    }
}

如果没有消息，这个循环会疯狂空转。

更合理的方式是等待消息：

rust 复制代码

while let Some(msg) = receiver.recv().await {
    handle(msg).await;
}

8.3 重连逻辑没有退避

rust 复制代码

loop {
    if connect().await.is_err() {
        continue;
    }
}

如果连接一直失败，它会疯狂重试。应该加退避。

8.4 日志刷屏

大量日志也会制造 CPU 和 I/O 压力，尤其是循环里打印日志。

8.5 Future 被频繁唤醒

异步 Rust 程序里，如果某个 Future 被错误地频繁唤醒，也会造成 CPU 空转。这种问题在网络服务、WebSocket、长连接、流式任务、状态轮询里比较常见。

9. 正确对比 dev 和 release 的方法

建议用同一套输入、同一套压测条件、同一台机器做对比。

9.1 构建 debug 版本

bash 复制代码

cargo build
./target/debug/your_app

查看 CPU：

bash 复制代码

top -p <pid>
pidstat -p <pid> 1

查看内存：

bash 复制代码

ps -o pid,%cpu,%mem,rss,vsz,cmd -p <pid>

9.2 构建 release 版本

bash 复制代码

cargo build --release
./target/release/your_app

再次查看 CPU、内存、延迟和吞吐。

9.3 服务压测

如果是 HTTP 服务，可以用：

bash 复制代码

wrk -t4 -c100 -d60s http://127.0.0.1:8080/

或者：

bash 复制代码

hey -z 60s -c 100 http://127.0.0.1:8080/

重点看：

text 复制代码

QPS
p50
p95
p99
错误率
CPU 占用
RSS 内存

不要只看 CPU 百分比。

正确判断方式是：

text 复制代码

同样 QPS 下，release CPU 是否更低？
同样 CPU 下，release QPS 是否更高？
同样请求下，release p95/p99 是否更低？

10. 生产环境应该怎么配置 release？

最基础的生产构建：

bash 复制代码

cargo build --release

如果只是普通服务，这已经足够。

如果想进一步优化，可以在 Cargo.toml 中配置：

toml 复制代码

[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
panic = "abort"
strip = true

这些配置的含义是：

opt-level = 3：开启较高等级运行时优化。默认 release 通常已经是这个级别。

lto = "thin"：启用 ThinLTO，做跨 crate 优化。

codegen-units = 1：让编译器更充分地做全局优化，代价是编译速度变慢。

panic = "abort"：panic 时直接终止进程，而不是展开栈。二进制体积可能更小，但 panic 后不能正常 unwind。

strip = true：移除符号信息，减小二进制体积。

不是所有项目一上来都需要这些配置。更合理的策略是：

text 复制代码

第一阶段：先用默认 cargo build --release
第二阶段：确认 CPU、吞吐、延迟、体积是瓶颈
第三阶段：逐项开启并压测验证

不要为了"看起来专业"盲目加配置。

11. dev build 和 release build 分别适合什么？

dev build 非常适合：

text 复制代码

日常开发
快速编译
本地调试
单元测试
断点调试
检查整数溢出
触发 debug_assert!
快速验证功能

release build 适合：

text 复制代码

生产部署
性能测试
压测
CPU 占用评估
延迟评估
吞吐评估
二进制发布
容器镜像构建
线上服务运行

所有性能相关判断，都应该基于 release build。

12. 常见误区

误区一：Rust debug 慢，所以 Rust 慢。

错误。Rust 的 debug 构建本来就不是性能模式。判断 Rust 性能必须看 release。

误区二：release 后 CPU 还是 100%，所以没优化。

不一定。如果压测把服务打满，release 仍然 100% 很正常。要看 QPS 和延迟。

误区三：release 一定更省内存。

不一定。CPU 通常会明显改善，内存要实测。

误区四：所有校验都可以写 debug_assert!。

错误。debug_assert! 在 release 下默认不执行。生产必须生效的校验应该用 assert! 或正常错误处理逻辑。

误区五：生产环境可以直接跑 cargo run。

不推荐。生产环境应该跑 release 二进制，或者在 Docker 构建阶段生成 release 产物，再复制到运行镜像中。

13. 最终结论

Rust 的 dev build 和 release build 不是简单的"调试版"和"正式版"名称差异，而是两套目标完全不同的构建策略。

dev build 面向开发效率：

bash 复制代码

cargo build
cargo run

它编译快，方便调试，但运行慢。

release build 面向生产运行：

bash 复制代码

cargo build --release
cargo run --release

它编译慢，但运行快。

如果你在 top 里看到 Rust 程序 CPU 占用偏高，第一件事不是怀疑 Rust，也不是立刻改代码，而是先确认你跑的是不是：

bash 复制代码

target/debug/

如果是，先换成：

bash 复制代码

target/release/

然后再评估 CPU、内存、QPS、p95、p99。

真正的判断标准是：

text 复制代码

开发调试看 dev
性能压测看 release
线上部署只看 release

不要用 target/debug 的表现评价 Rust 程序的最终性能。

参考资料

The Cargo Book: Profiles: doc.rust-lang.org/cargo/refer...
The Cargo Book: cargo build: doc.rust-lang.org/cargo/comma...
Rust standard library: debug_assert!: doc.rust-lang.org/std/macro.d...

错误速查卡

症状	根因	定位	修复
`cargo run` 后 CPU 占用 80%+，怀疑 Rust 性能差	跑的是 `target/debug`（`dev profile`，`opt-level = 0`）	`ls target/` 或 `ps` 看进程路径	改用 `cargo run --release` / `cargo build --release` 后再评估
切到 release 后 CPU 仍然 100%	压测打满而非固定负载，QPS 提升了	同时看 QPS、p50/p95/p99、wrk/hey 报告	改用"同 QPS 比 CPU、同 CPU 比 QPS、同请求比 p95/p99"三种判断方式
release 后内存几乎没下降甚至略涨	内联/循环展开增加了代码段、debug 信息未完全剥离	`ps -o rss,vsz -p <pid>`、`size target/release/your_app`	接受内存可能不退；如要瘦二进制加 `strip = true`、`lto = "thin"`、`panic = "abort"`
`debug_assert!(x == 2)` 线上没拦住问题	`debug_assert!` 在 release 下默认不执行	grep 源码 + 复现 release 构建	把生产必须校验改成 `assert!` 或正常错误处理
`u8 = 255; u8 + 1` 在 release 下没 panic 而是变 0	release 默认关闭 `overflow-checks`，按回绕处理	`cargo build --release` 复现	业务依赖溢出 panic 时，在 `[profile.release]` 显式加 `overflow-checks = true`
空闲状态 CPU 仍高，release 也救不了	死循环/空转/无退避重连/日志刷屏/Future 频繁唤醒	`top -p <pid>`、`pidstat`、strace/profiling	加 sleep/退避、用 `recv().await`、限流日志、检查 waker
线上直接 `cargo run`，容器里也没做 release	dev 构建被部署到生产	`cat Dockerfile`、镜像内 `ls target/`	Docker 多阶段构建：第一阶段 `cargo build --release`，第二阶段只 COPY `target/release/your_app`
加了一堆 `[profile.release]` 配置反而没提升	默认 release 已是 `opt-level = 3`，冗余配置引入编译变慢等代价	对比默认 release 压测基线	先用默认 release，逐项（`lto`/`codegen-units`/`strip`/`panic`）单独 A/B 验证收益

调查研究-201 Rust 里的 dev build 和 release build：为什么同一份代码性能差这么多？

TL;DR

版本矩阵

TL;DR

1. 问题从哪里来？

2. cargo build 到底做了什么？

3. cargo build --release 到底做了什么？

4. 性能一般能差多少？

5. 为什么 dev build 会慢？

5.1 函数内联少

5.2 循环优化弱

5.3 边界检查更难被消除

5.4 整数溢出检查

5.5 debug_assert! 行为不同

6. CPU 占用会不会因为 release 下降？

7. 内存占用会不会因为 release 下降？

8. 空闲 CPU 也高，release 不一定能救

8.1 死循环没有 sleep

8.2 channel 接收失败后立刻重试

8.3 重连逻辑没有退避

8.4 日志刷屏

8.5 Future 被频繁唤醒

9. 正确对比 dev 和 release 的方法

9.1 构建 debug 版本

9.2 构建 release 版本

9.3 服务压测

10. 生产环境应该怎么配置 release？

11. dev build 和 release build 分别适合什么？

12. 常见误区

13. 最终结论

参考资料

错误速查卡

2. `cargo build` 到底做了什么？

3. `cargo build --release` 到底做了什么？

5.5 `debug_assert!` 行为不同