MangoDisk

开发者磁盘清理

Cargo 缓存和 target 目录有什么区别？Rust 开发者该删哪个

了解 Rust 项目 target 构建产物与 Cargo 依赖缓存的区别、哪些可以安全删除，以及 .cargo 目录中哪些内容绝对不应当作缓存清理

发布于 2026年8月12日作者： Harry
将 Rust 依赖包与项目构建产物分开检查后再安全清理

磁盘空间不足时，通常应该先清理不再活跃项目的 target 目录。这里保存的是单个 Rust workspace 的构建产物，之后重新编译即可生成。只有在 Cargo 的共享依赖缓存确实很大、已经损坏，或者近期不需要离线开发时，才考虑清理它；代价是后续需要重新下载或解压依赖。

不要直接删除整个 .cargo 目录。这里还可能包含 Cargo 配置、registry 凭据，以及通过 cargo install 安装的命令行工具，它们都不是可以随手删除的缓存。

本文路径与命令于 2026 年 8 月 12 日在 macOS 15.7.7、Cargo 1.84.0 和 rustc 1.84.0 环境验证。Cargo 支持自定义 Home 和构建目录，执行清理前请以自己机器上的实际路径为准。

简单结论：先清 target，再考虑 Cargo 缓存

Cargo 会保存两类性质不同、但都可以重新生成的数据：

  • workspace 中的 target 目录，保存这个项目的编译结果；
  • Cargo Home（通常为 ~/.cargo），保存共享下载、解压后的依赖源码、Git 依赖、配置、凭据和已安装工具。

区别在于恢复成本。删除 target 主要损失编译时间；删除依赖缓存还可能需要网络和重新编译。因此，对大多数开发者来说，废弃项目的 target 是更合适的第一清理目标。

路径包含内容是否可以删除删除后的影响
project/targetDebug、Release、增量编译、文档和不同目标平台的构建产物可以，先停止构建项目需要重新编译
~/.cargo/registry/cache已下载的 crate 压缩包通常可以，但要确保能够联网Cargo 会重新下载缺失的 crate
~/.cargo/registry/src从 registry 解压出的依赖源码通常可以，但要确保能够联网Cargo 会重新解压或下载
~/.cargo/git/db 和 git/checkoutsGit 依赖仓库及其 checkout通常可以，但要确保能够联网Cargo 会重新拉取和 checkout
~/.cargo/bin通过 cargo install 安装的工具不可以当作缓存删除已安装命令会消失
config.toml 和 credentials.tomlCargo 设置和 registry 凭据不可以构建、registry、代理或登录可能失效
Cargo.toml、Cargo.lock、src项目定义、依赖锁定和源代码不可以会直接破坏项目

Windows 的默认 Cargo Home 通常是 %USERPROFILE%\.cargo。如果设置了 CARGO_HOME，无论使用哪个系统，都应以该环境变量指向的位置为准。

target 目录为什么会越来越大？

Cargo 默认把构建输出写入 workspace 的 target 目录。Debug 和 Release profile 使用不同的子目录；增加编译目标后，不同 target triple 也会保存各自的产物。增量编译还会保留中间数据，以缩短后续构建时间。

如果一个 workspace 同时构建桌面程序、WebAssembly、多个架构或多套 feature，累计占用远高于源代码大小很正常。Cargo 官方将这些内容视为可以重新生成的构建数据，但删除仍有明确代价：下一次构建会从冷缓存开始。

本文实测的 MangoDisk 仓库中，target 占用了 27 GB。同一台 Mac 上，Cargo registry 压缩包缓存为 189 MB，解压源码为 1.9 GB，Git 数据库为 17 MB。这只是当前机器的实际结果，不代表每个人都能释放同样空间；它说明了为什么应该先测量，而不是默认全局 Cargo 缓存最大。

清理前先确认真实路径和大小

在 macOS 或 Linux 的 Rust workspace 中，可以先执行这些只读命令：

cargo_home="${CARGO_HOME:-$HOME/.cargo}"

du -sh target 2>/dev/null
du -sh "$cargo_home/registry/cache" "$cargo_home/registry/src" \
  "$cargo_home/git/db" "$cargo_home/git/checkouts" 2>/dev/null

Cargo 也可能使用自定义 target 目录。下面的命令会输出 workspace 元数据，其中包含实际的 target_directory：

cargo metadata --no-deps --format-version 1

在 PowerShell 中，可以分别检查当前项目和默认 Cargo Home：

$CargoHome = if ($env:CARGO_HOME) { $env:CARGO_HOME } else { Join-Path $HOME ".cargo" }

Get-ChildItem .\target -Recurse -File -Force -ErrorAction SilentlyContinue |
  Measure-Object Length -Sum
Get-ChildItem "$CargoHome\registry\cache" -Recurse -File -Force -ErrorAction SilentlyContinue |
  Measure-Object Length -Sum

PowerShell 结果以字节为单位。更重要的是，检查过程能让你在删除前再次确认路径。

如何安全清理项目 target 目录

先停止 cargo build、测试、正在编译的 rust-analyzer 任务，以及从该 workspace 启动的程序。然后预览 Cargo 准备删除的内容：

cargo clean --dry-run -v

确认范围无误后，清理当前 workspace 的完整 target 目录：

cargo clean

如果还想保留有用的构建数据，可以缩小清理范围：

# 只删除 Release profile 的构建产物
cargo clean --release

# 只删除生成的文档
cargo clean --doc

# 只删除 workspace 中一个 package 的构建产物
cargo clean -p your-package-name

cargo clean 会遵循 Cargo 配置中的 target 目录。对使用自定义 target-dir 的 workspace 来说，这比手动假设目录一定是 ./target 更稳妥。

清理后目录重新出现是正常现象。下一次构建会创建它；由于增量编译数据已经删除，第一次完整编译通常会明显变慢。

什么情况下应该清理 Cargo 共享缓存？

以下情况适合考虑清理：

  • 实测缓存占用已经大到值得处理；
  • 下载的压缩包或 Git 依赖已经损坏；
  • 旧工具链和项目留下了近期不会再用的依赖；
  • 现在必须释放空间，而且之后有可靠网络可以恢复依赖。

准备乘飞机、需要离线工作或内部 registry 可能不可用时，不建议清理。动手前还应确认团队是否使用了自定义 registry、vendored dependencies 或非默认 CARGO_HOME。

Cargo Home 官方文档把 registry 和 Git 相关内容描述为可通过重新解压、checkout 或下载恢复的缓存。如果决定手动删除，请先退出 Cargo 相关进程，设置准确的 Cargo Home，并最后检查一次：

cargo_home="${CARGO_HOME:-$HOME/.cargo}"
du -sh "$cargo_home/registry/cache" "$cargo_home/registry/src" \
  "$cargo_home/git/db" "$cargo_home/git/checkouts" 2>/dev/null

然后只删除自己明确选中的缓存子目录：

rm -rf "$cargo_home/registry/cache" "$cargo_home/registry/src" \
  "$cargo_home/git/db" "$cargo_home/git/checkouts"

该命令不会经过废纸篓，绝对不要把它简化成 rm -rf ~/.cargo。清理后，下一次联网构建可能会重新下载和解压依赖。

Windows 用户可以使用文件资源管理器，查看并删除 %CARGO_HOME% 或 %USERPROFILE%\.cargo 下对应的缓存子目录。可视化确认能降低误选 bin、配置或凭据文件的风险。

哪些内容绝对不能当作 Cargo 缓存删除？

不要把这些内容列为清理目标：

  • .cargo/bin：这里保存 cargo-audit、cargo-edit 等已安装命令；
  • .cargo/credentials.toml：这里可能保存 registry 登录令牌；
  • .cargo/config.toml：这里可能定义 registry、alias、网络设置和编译目标行为；
  • 项目中的 Cargo.toml、Cargo.lock、build.rs 或 src；
  • vendored dependencies 或团队维护的离线镜像，除非负责人已经制定恢复方案。

如果不能确认某个目录是否只是缓存，就停在查看步骤。内容位于 .cargo 下面，并不等于可以随意删除。

使用 MangoDisk 检查 Rust 构建产物

MangoDisk 深度清理可以识别 Rust 项目的 target 目录，以及不同平台对应的 Cargo 缓存位置。规则不会把整个 .cargo 作为清理目标，项目构建产物也不会默认选中。

扫描在本地完成。你可以先查看路径和实际大小，再决定是否删除；当多个 workspace 各自保存了 target 时尤其方便。完整确认和清理历史流程可以查看 MangoDisk 安全指南。

常见问题

Rust 项目的 target 目录可以安全删除吗？

可以，前提是它确实是 Cargo 配置的构建输出目录，而且当前没有构建任务。这里保存的是可重新生成的产物，不是项目源代码；删除后需要接受一次更慢的完整编译。

cargo clean 会清理 Cargo 下载缓存吗？

不会。cargo clean 删除的是 target 目录中的构建产物，不会清空 Cargo Home 中的 registry 或 Git 依赖缓存。

可以删除 Cargo.lock 来省空间或修复依赖吗？

不可以。Cargo.lock 很小，用于记录已经解析的依赖版本。删除它不是磁盘清理，还可能让 Cargo 选择不同的依赖版本。

为什么 Cargo 缓存和 target 又出现了？

这是正常现象。项目构建时，Cargo 会重新生成构建产物并恢复缺失的依赖。清理只是删除旧的可再生数据，不会关闭缓存机制。

资料来源与延伸阅读

希望先直观看清 Rust 构建产物和 Cargo 缓存再决定是否删除？可以下载 MangoDisk，在本地检查扫描结果。

Cargo 缓存Rust target 目录cargo clean开发者磁盘清理
全部文章