本文永久链接 – https://tonybai.com/2026/06/30/rust-project-eating-75gb-disk-space-go-vs-rust-cache-anxiety
大家好，我是Tony Bai。
在系统级编程的世界里，开发者们似乎永远在为两件事焦虑：一是代码能不能编译通过，二是编译究竟要花多长时间。
为了解决第二个问题，现代编译器进化出了极度贪婪的“胃口”。它们在你的本地疯狂下载依赖、保存中间产物、缓存增量编译结果——用一种近乎粗暴的方式，拿你的物理硬盘空间，去换取你生命中的几秒钟编译时间。
最近，在 Reddit 的 r/rust 社区， 一位开发者发帖求助：《我的 Rust 工作区（Workspace）达到了 75GB，对于长期项目来说，这正常吗？》 ，这个经过几个月开发的项目，其 target 目录已经被塞得满满当当。
原以为大家会帮他排查问题，没想到评论区瞬间变成了“比惨大会”和“凡尔赛现场”：
cargo clean，清出了 300GB 空间，感觉整个人都升华了。”面对这种夸张的“磁盘吞噬战”，无论是深陷 target 泥潭的 Rust 玩家，还是常年看着 GOMODCACHE 日益膨胀的 Go 语言开发者，都患上了严重的“缓存焦虑症”。
今天，我们就来深度剖析一下：为什么现代编译器变得如此贪吃？我们又该如何通过社区的黑科技与官方的底层机制，拯救我们奄奄一息的固态硬盘？
虽然最终结果都是“磁盘空间不足（Disk Full）”，但 Rust 和 Go “吃硬盘”的姿势和底层逻辑却截然不同。
target/ 目录在 Rust 中，万恶之源就在你项目根目录下的那个 target/ 文件夹。如果你用 du -sh target/ 查看一下，你大概率会被那个数字吓倒。
Rust 极其贪吃的原因有三个：
tokio 和 serde，那么这 10 个项目会各自在自己的 target/ 目录下把这两个庞然大物重新编译一遍，并保存中间件。dev 模式、release 模式、甚至你切换了一次 Rustc 的版本（比如从 1.94.0 升到 1.95.0），旧版本的编译构件（Artifacts）都不会被自动删除，而是层层叠加。pkg/mod 与 GOCACHE相比之下，Go 的设计哲学显得更为全局观，但同样不可避免地会随着时间的推移而“发福”。
自 Go Modules 普及以来，Go 放弃了基于项目局部的 vendor 目录，转而将所有依赖都下载到了一个全局的、不可变的目录中（通常是 ~/go/pkg/mod）。
go env GOCACHE 查看）。这里面塞满了编译过的包对象（.a 文件），这让你在修改自己的代码时，不需要重新编译标准库和第三方库。对于被 target 目录折磨的 Rustacean 来说，生存策略可以分为“毁灭性打击”和“精准优化”两种。
cargo clean这是最解压的命令。敲下 cargo clean，几百 GB 的空间瞬间释放。
但代价是惨痛的——下次编译时，你将不得不花上几十分钟盯着屏幕上的 Compiling xxx 进度条发呆。这属于典型的“爽一时，痛一天”。
为了不把洗澡水和孩子一起倒掉，Reddit 上的老手们推荐了一系列神器：
cargo-sweep：这是一个极其优雅的插件。你可以用 cargo sweep --installed 清理掉那些属于旧版本编译器的残留构件；或者用 cargo sweep --time 30 删掉过去 30 天都没有被访问过的僵尸文件。sccache：这是由 Mozilla 开发的神器，相当于 C/C++ 世界的 ccache。它不仅能接管编译缓存，还能在多个不相关的 Rust 项目之间共享相同的依赖编译结果。当你开启 sccache 后，那些重复的 tokio 编译噩梦将不复存在。kondo：如果你是一个全栈开发者，电脑里混杂了大量的 Rust、Node.js (node_modules) 和 Go 项目。这个命令行工具可以一键帮你递归扫描并清理所有项目的构建垃圾。许多拥有多个相关 Rust 仓库的开发者，会在 ~/.cargo/config.toml 中配置全局的 build.target-dir。
[build]
target-dir = "/path/to/global/target"
这样，所有的项目都会把编译产物丢进同一个大池子里。虽然这个池子依然会变大，但至少你享受到了跨项目的依赖复用红利。
与 Rust 社区依靠丰富的第三方插件进行“自救”不同，Go 语言的解决方案往往带有强烈的“官方统筹”与“工程极简”色彩。
在依赖与缓存管理上，Go 官方其实在底层布下了多道防线，甚至开放了极其前沿的黑科技。
GOCACHE不同于 Rust 那个只要你不删就永远存在的 target 目录，Go 的 GOCACHE 机制自带了一个非常克制的自动垃圾回收（GC）机制。
Go 会自动跟踪缓存项的最近使用时间（mtime）。Go 命令在退出时，会检查距离上次清扫是否已超过 1 天，若是则触发一次扫描，删除那些超过 5 天未被访问的构建缓存条目。这也是 Go 开发者很少会遇到单一缓存目录膨胀到几百 GB 的原因。
// $GOROOT/src/cmd/go/internal/cache/cache.go
// Time constants for cache expiration.
//
// We set the mtime on a cache file on each use, but at most one per mtimeInterval (1 hour),
// to avoid causing many unnecessary inode updates. The mtimes therefore
// roughly reflect "time of last use" but may in fact be older by at most an hour.
//
// We scan the cache for entries to delete at most once per trimInterval (1 day).
//
// When we do scan the cache, we delete entries that have not been used for
// at least trimLimit (5 days). Statistics gathered from a month of usage by
// Go developers found that essentially all reuse of cached entries happened
// within 5 days of the previous reuse. See golang.org/issue/22990.
const (
mtimeInterval = 1 * time.Hour
trimInterval = 24 * time.Hour
trimLimit = 5 * 24 * time.Hour
)
如果你真的硬盘见底了，Go 也提供了两个极其安全的一键清理指令：
go clean -cache：清空编译缓存（和Rust一样，下次编译会变慢，但不会丢失源码）。go clean -modcache：清空下载的全局 Module 依赖源码（下次编译会重新联网下载代码）。GOCACHEPROG 协议的无限想象这是 Go 1.21 以实验性功能引入、并在 Go 1.24 正式稳定的一个鲜为人知、但极具颠覆性的环境变量—— GOCACHEPROG。
在过去，构建缓存只能老老实实地写在本地硬盘上。但 Go 团队意识到，对于大型微服务团队和 CI/CD 平台来说，局部的硬盘缓存已经满足不了需求了。
通过实现 GOCACHEPROG 接口，开发者可以编写一个独立的、与 Go 编译器通信的外部程序，彻底接管缓存的读取与写入逻辑！
这意味着什么？
对于Go mod cache的膨胀问题，Go 的社区目前也在积极探讨对 pkg/mod 目录的物理优化，包括希望提供module 的remove命令来支持手动删除Go module cache目录下的某个版本的go module。
由于解压后的 Module 源码包含大量的碎小文件，这会极其消耗 Linux 系统的 inode 资源和磁盘空间。社区中已有第三方工具（如 Tailscale 开源的 gomodfs）探索以 FUSE/NFS 方式将 zip 格式的依赖包直接挂载为文件系统，从而避免解压带来的磁盘和 inode 开销。
从 Reddit 上的“75GB 惨案”，到各大语言社区绞尽脑汁的缓存优化，我们看到的是软件工程学中最经典的博弈：空间换时间。
编译器是聪明的。它知道程序员的薪水（时间）比固态硬盘要昂贵得多。所以，它宁愿被骂作“硬盘杀手”，也要尽可能把一切中间状态缓存下来，只为了在你按下 Ctrl+S 的那一刻，能以最快的速度把报错信息拍在你脸上。
幸运的是，无论是 Rust 社区诸如 sccache 的极客工具，还是 Go 语言底层开放的 GOCACHEPROG 协议，都在向我们证明：随着云原生和分布式编译的演进，我们终将打破单机物理硬盘的桎梏。
最后，敲下这篇文章时，我默默看了一眼我的 ~/.cargo/ 和 ~/go/ 目录。
那么，正在阅读这篇文章的你，敢不敢在终端里输入一行 du -sh，在评论区晒出你的“硬盘惨案”呢？
资料链接：https://www.reddit.com/r/rust/comments/1ufaef8/my_rust_workspace_is_75gb_is_this_normal_for/
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。