你的MacBook硬盘是怎么消失的？答案藏在每个Rust项目的target/文件夹里——那里躺着5到15GB的"编译尸体"，10个项目就是50到150GB。这不是bug，是Rust为速度和正确性支付的磁盘税。

一图读懂：10GB去哪儿了

打开网易新闻 查看精彩图片

Rust的编译模型像一家从不扔草稿的设计工作室。为了让你改一行代码只需几秒而非几分钟，它把每一次中间状态都存进硬盘。debug信息、增量编译快照、依赖库的本地编译副本、多目标多配置的组合爆炸——四层叠加，空间就这样被吃干抹净。

下面逐层拆解这张"账单"。

第一层：Debug信息，体积翻倍的三明治

默认的cargo build会塞满DWARF调试信息——函数名、变量位置、类型定义、行号映射。这些对人类友好，对磁盘残忍。

一个"hello world"的debug二进制文件约3-4MB。加上几个真实依赖？最终二进制轻松50-200MB，还没算中间产物。调试信息本身就能把机器码体积翻两到三倍。

第二层：增量编译，速度与空间的对赌

Rust的增量编译是迭代速度的救命稻草。改一行代码，只重编译变更部分——否则大型项目每次改动都要等几分钟。

代价是target/debug/incremental/里的快照会膨胀到数GB。每次代码变更产生新快照，旧快照清理又不积极。这是显式的空间换时间。

第三层：依赖编译，没有预编译包的代价

运行cargo build时，编译器不只是编译你的代码——它从源码编译每一个依赖。典型Rust项目有100-300个传递依赖（用cargo tree | wc -l自查），每个crate都生成.rlib文件、元数据、构建脚本输出，全部塞进target/。

Python有wheels，npm有prebuilds，Rust没有。一切本地编译，一切本地存储。

第四层：配置组合，四份全套副本

target/的膨胀还来自多配置并行：

• target/debug/ —— 默认cargo build输出

• target/release/ —— cargo build --release，完全独立的编译和产物

• target// —— 交叉编译目标，如aarch64-apple-darwin或wasm32-unknown-unknown

每个配置组合拥有一套完整的依赖编译产物。两个目标 × debug/release两种模式 = 四份全套副本。

为什么Rust不"优化"掉这些

这不是疏忽，是设计权衡。Rust的编译模型优先考虑：运行时性能、编译正确性、开发者迭代速度。磁盘空间是显式牺牲的变量。

理解这些机制后，清理和防膨胀才有针对性——知道哪些能删、哪些删了会慢、哪些配置根本用不上。

冷幽默

下次有人抱怨MacBook 256GB不够用，先检查他是不是偷偷养了十个Rust项目。毕竟，在Rust的世界里，"Hello World"的体重和一只猫差不多——而你的依赖树，是一片热带雨林。