Rust target 目录太大？编译产物膨胀的诊断、清理与优化指南

你要解决的是哪一种“大”

在一个日常开发的 Rust 项目中，target 可能很快从“看起来正常”变成十几 GB：

2.3G    ./target/aarch64-apple-darwin
1.3G    ./target/release
504K    ./target/flycheck0
0B      ./target/tmp
11G     ./target/debug
14G     ./target

这并不自动说明 Cargo 出了问题。target 同时保存构建缓存、中间产物和最终可执行文件；不同目标、Profile 与编译配置会累积成多套产物。先区分目标，才能避免用“删缓存”的方式误处理“发布包太大”的问题。

目标	首要操作	主要代价
立即释放当前项目的磁盘空间	`cargo clean` 或仅清理指定 Profile	下次构建需要重新编译
减少相近项目间的重复构建产物	共享 `target-dir` 或使用 `sccache`	需要处理锁竞争、配置差异与额外的缓存维护
缩小要发布的二进制文件	调整 Release Profile 并裁剪 feature	构建时间变长，或运行时行为发生变化

target 为什么会膨胀

target/debug/ 是默认开发构建的输出，便于快速迭代；target/release/ 是 --release 构建的输出，优化策略不同，因此不会与 debug 共用文件。target/debug/incremental/ 保存增量编译状态，以更多磁盘空间换取后续改动后的更快重编译。

同一层级还常见这些目录：

deps/：当前包和依赖的编译产物、元数据与链接所需文件。
build/：依赖的 build script 及其生成结果，例如绑定代码、探测结果或本地库配置。
incremental/：编译器的增量状态；关闭它可以省空间，但会降低反复修改后的构建速度。

交叉编译会加入目标三元组目录，例如 aarch64-apple-darwin/；每个 target 都需要自己的一组产物。编辑器的检查任务也可能创建 flycheck0/ 等临时输出。除此以外，dev、release、自定义 Profile，以及同一 Profile 下的 feature、依赖版本、工具链和编译参数差异，都会让看似相同的构建各自留下缓存。

先确定，再删除

先确认是哪个子目录在增长，而不是直接清空所有内容：

du -sh target
du -sh target/* 2>/dev/null | sort -h

如果最大的是 debug/，通常应检查开发 Profile、增量编译和本地迭代方式；如果是某个 target triple，考虑是否仍需要该交叉编译目标；若 release/ 或最终二进制很大，则转到本文的 Release 优化。Cargo Home 中的 registry 与 Git 下载缓存是另一类空间来源，不能把它和项目 target 混为一谈。

快速释放空间：cargo clean

空间必须立刻腾出时，使用 Cargo 清理，而不是手工猜测哪些文件能删：

cargo clean
cargo clean --release

第一个命令移除当前项目的构建产物，下一次构建需要重新编译；第二个命令只清理 Release 输出，适合确认不再需要发布产物时使用。清理前若要保留可复现的构建信息，应确保 Cargo.lock 已提交；它不会代替构建缓存，却能固定依赖解析结果。

不要在不了解影响范围时删除共享目录：一旦多个项目共用同一个 target-dir，对该目录执行 cargo clean 或直接删除它，会影响每一个使用它的项目，并让它们在下次构建时重新编译。

共享 target-dir：有效，但不是万能方案

相近项目频繁重复编译同一批依赖时，可以把输出移到统一目录。若只对当前项目生效，请把以下配置写入项目根目录的 .cargo/config.toml，不要写进 Cargo.toml：

[build]
target-dir = "/Users/your-name/.cargo-target"

若要设为全局默认值，可将同一段 [build] 配置改写到 $CARGO_HOME/config.toml。

也可以让 shell 环境变量覆盖默认目录：

export CARGO_TARGET_DIR="$HOME/.cargo-target"

共享目录并不会让所有构建天然复用。收益取决于 package 版本、启用的 features、Profile、编译 target、Rust toolchain、RUSTFLAGS 及其他相关输入是否匹配；任一组合不同，Cargo 仍会存放另一套产物。因此它更适合有稳定依赖组合的一组项目，而非“所有 Rust 项目一律共用”的默认设置。

并发也是取舍的一部分。稳定版 Cargo 共享一个构建缓存时，项目可能因缓存锁而串行等待；更细粒度的缓存锁仍是 unstable 能力。若经常并行构建彼此差异很大的项目，独立 target 目录往往更可预测。

定期清理旧产物

不想每次都从零编译，可以保留近期项目、按时间回收长期不用的目录。cargo-sweep 是第三方工具，先用 dry run 核对计划，再真正执行：

cargo install cargo-sweep
cargo sweep --dry-run --time 30
cargo sweep --time 30

上例以 30 天为阈值；实际策略应按磁盘容量和项目活跃度调整。另一种方式是用时间戳标识仍在使用的工作区：

cargo sweep --stamp
# Run normal builds and tests for a period of time.
cargo sweep --file

先写入 stamp，再在一段正常构建和测试周期后按 stamp file 回收未更新的旧产物，适合希望先观察而非立即批量删除的团队。无论采用哪种方式，都应在 CI、共享目录或重要分支上先验证工具行为，并保留可重新构建所需的源码与锁文件。

对于包含多个工作区的父目录，cargo-sweep 还可按其文档的递归清理模式处理子目录；扩大扫描范围前同样应先用dry run，确认不会触及仍在使用的构建目录。

cargo-cache、 cargo-reclaim 也都是可选的第三方工具，不是 Cargo 核心命令。它们覆盖的缓存位置、维护活跃度和删除策略各不相同；尤其是会清理目录的操作，应先阅读当前版本文档、确认作用范围，并在可恢复的环境中试跑。

Cargo 自动 GC 能清什么

Cargo 1.88+ 已会自动清理 Cargo Home 中未使用的 registry、Git 数据等全局下载缓存。这是稳定 Cargo 的自动回收范围，能帮助控制下载缓存，但尚未实现项目 target 构建产物的追踪与自动清理。

如果要试验 Cargo 的手动 GC，只能在 Nightly 上使用以下不稳定命令：

cargo +nightly clean gc -Zgc

它依赖 -Zgc，接口和行为都可能变化，不应把它写进要求稳定 Cargo 的日常脚本。对稳定工具链而言，cargo clean、明确的目录策略与经过检查的第三方回收工具仍是可预期的选择。

从源头减少开发构建体积

对于本地开发，调试信息与依赖的调试信息常是 debug/ 变大的主要原因。可以在 Cargo.toml 中只保留line-tables调试信息，并关闭依赖包的调试信息：

[profile.dev]
debug = "line-tables-only"

[profile.dev.package."*"]
debug = false

这样通常能减少开发构建中的调试数据；代价是调试器可见的变量、完整类型等信息减少，而依赖内部的调试体验也会变弱。先在团队最常用的调试场景中验证，再决定是否全局采用。

若磁盘比增量构建速度更重要，还可单独加入：

[profile.dev]
incremental = false

这会停止保存增量状态，因而减少 incremental/ 的占用；代价是代码改动后的 rebuild 通常更慢。本文不把 split-debuginfo = "unpacked" 列为通用节省空间开关：在 macOS 启用调试信息时它本来就是 Cargo 的默认行为，跨平台效果与取舍也不相同。

缩小最终 Release 二进制

先做低风险检查：审视依赖图与 Cargo features，移除未用的可选功能、默认 feature 或不需要的依赖。feature 裁剪常能直接减少被链接进最终程序的代码，且不会先改变编译器的优化语义。

随后可以针对发布二进制评估如下 Profile：

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

opt-level = "z" 优先倾向体积；也应实测 "s" 与 "z"，不同程序、依赖和链接器下没有一个设置保证总是更小。lto = true 可在链接时跨 crate 优化，但通常拉长构建时间；codegen-units = 1 可能改善优化机会，也会降低并行代码生成度并增加构建时间。strip = "symbols" 去掉符号信息，可能让诊断和二进制分析更困难。panic = "abort" 可减小体积，却会把 panic 从展开栈改为直接终止进程，必须确认业务的恢复、清理与错误处理假设仍成立。

这些设置治理的是最终 Release 可执行文件，不等同于清理整个 target。把它们用于每次开发构建，常会换来更慢的反馈周期。

sccache 与 Nightly 进阶选项

当多个工作区重复编译相同依赖时，sccache 可以缓存 Rust 编译结果，降低重复编译成本：

cargo install sccache
export RUSTC_WRAPPER=sccache

它是编译缓存工具，不是清理工具；其自身也会占用缓存空间，需要纳入监控与回收策略。对于远程或 CI 缓存，还要评估访问权限、失效规则和网络成本。

Nightly 还提供一项实验性选择：

cargo +nightly -Zno-embed-metadata build

它不属于稳定接口，适用性和节省效果应由自己的项目测量决定；本文不为它给出固定节省比例。升级 Nightly 或 Rust 编译器后，也应重新验证构建产物、调试体验与发布流程。

按场景选择日常工作流

个人笔记本：先用 du 找到增长位置；空间告急就执行 cargo clean，平时保留每个项目自己的 target，再按需降低 dev 调试信息或关闭增量编译。
并行多项目开发：不要默认全局共享 target-dir。只有依赖与配置高度一致、并发等待可接受时再共享；否则优先独立目录，或试用 sccache 并为它设定缓存上限与回收计划。
CI：把依赖下载缓存与构建产物缓存分别设计，并以 Cargo.lock、target、Profile、Rust 版本和编译 flags 作为 cache key 的输入。设置 TTL 或大小上限，避免缓存无限累积；不要依赖本机共享目录的偶然命中。
单体仓库（monorepo）：工作区本来就适合在一个构建图内共享依赖。保持统一的 toolchain、features 与 Profile，定期观察 target 增长；对长期闲置的工作区使用经 dry run 确认的定期回收策略。

总结

target 大的根本原因通常是“保留了许多不同构建组合”，而不是某一个可以无代价关闭的缓存。紧急情况用 cargo clean；需要跨项目复用时谨慎评估共享目录和sccache；如果Release版本的二进制文件太大，先裁剪 features，再实测 Release Profile。

把构建产物、Cargo Home 下载缓存和发布二进制当成三个独立问题处理，才能在磁盘空间、构建速度、并发能力和运行时行为之间做出清楚的取舍。

官方与工具参考

Cargo 官方： Build Cache、Configuration、Profiles、cargo clean。
Cargo unstable：gc、no-embed-metadata。
Cargo 版本变更： Cargo CHANGELOG。
第三方工具：cargo-sweep、cargo-cache、sccache、cargo-reclaim。