Cargo

原文：Infrastructure for Agentic Rust （2026-10-05，作者 Jonathan Ellis） 我的大半个职业生涯都在 Java 和 Python 这类托管运行时语言中度过，所以转向 Rust 时，等着我的是几颗新地雷 。到现在，我以 Rust 为主要语言写代码已经大约六个月了——或者更准确地说，是"让代码被写出来 "——我想我终于快到雷区的另一头了。 以下是我踩过的一些地雷。如果你还生活在 2023 年、一行一行手写代码，它们大多只是小烦恼；但当它们被十几个同时撞上来的 agent 一放大，就绝对能毁掉你的一天。 地雷 #1：Cargo 是个糟糕的室友 即使是我这样的 Java 程序员也知道 rustc 很慢。但我不知道的是，cargo 默认就会让 target/ 越涨越大，直到磁盘被写爆（ENOSPC）。 解法 #1：MBX Rustaceans 用 sccache 和 cargo-sweep 已经很多年了，而最近 Jeff Dickey 做出了 Mr. Boxington （即 mbx），带来了一批 Rust 专属的体验升级。毫不夸张地说：只要你还在调用 rustc，你就应该用 mbx。它为你做了这些事： 自动清理 target/。 用 reflink 在多次构建之间共享已编译的依赖，所以无论同时跑着多少个 worktree 或 agent，依赖都只需要构建一次。（但请读一读 share_workspace_root 相关的细则。） 同样用 reflink 共享已完成的 crate，细则见下文。 还有一个服务端版本，能把第 2、3 项部署到 AWS 上，让整个团队受益。 （与大多数构建缓存不同）它和增量构建相处得很好。 当 Cargo 试图耗尽你的磁盘时，给你一个统一的"咽喉"可以掐住。 可以按需限制构建占用的 CPU 和内存，减少资源争抢、防止 OOM。 地雷 #2：Rust 构建产物大得吓人 这与第 1 条相关但又不同：即使你的 target 目录修剪得整整齐齐、没有早期构建留下的垃圾，cargo 的工作集依然大得惊人。我投入时间最多的 Rust 项目是 Bifrost ，它一个正常的 target 目录就有 52GB。（我希望能有位 Ward Cunningham 附体的人出面告诉我，怎么把它砍到五分之一甚至十分之一；但据 Fable 和 Astra 告诉我的，在 Rust 这片地界，事情就是这样。是的，我们已经开启了 line-tables-only。） ...