你有没有想过，每一次在终端敲下
cargo add或cargo build，那些包是从哪里来的，又是怎么以这么快的速度送到你手边的？
RustConf 2025 在美国西雅图举办。会议的最后一个小时，Rust 项目 Content Team 的 Xander Cesari 和 Rust 基础设施团队（Infra Team）的工程师 Jan David Nose（江湖人称 JD）坐下来，聊了聊这个"让 Rust 得以运转"的幕后团队，以及他们正在面对的种种挑战。
本文就整理自 Rust 官方博客 RustConf 2025 系列访谈，原文为 Xander Cesari 与 Jan David Nose 的对话实录。
基础设施团队做什么？
很多人用 Rust 很久了，却不知道 Infra Team 的存在。JD 给出了一个清晰的定位：这个团队服务两类人，一是语言的用户，二是语言的维护者。
对维护者而言，Infra Team 负责 Rust 从代码提交到发布的整个流水线------CI/CD、GitHub 上的机器人和分类工具、PR 的标签管理，等等。一个 PR 从开出到合并，背后有无数自动化工具在默默检查。
对普通用户而言，最直接的影响是 crates.io 的下载体验。crates.io 的 Web 应用和 API 由单独的 crates.io 团队负责，但所有的 crate 文件都存放在 Infra Team 维护的基础设施上，并通过他们管理的 CDN 分发到全球。
用 JD 自己的话说："如果我工作没做好，crates.io 就会全球宕机，没有人能下载任何东西。"
每个月六年的 CPU 时间
Rust 对平台支持的广度是出了名的。Tier 1 目标需要完整测试，Tier 2 目标要尽力覆盖，甚至 Tier 3 也在可能的情况下跑一些测试。
这导致 Rust 的 CI 流水线极其庞大。JD 透露了一个令人震惊的数字：每个月累计超过三百万分钟的构建时间，折算下来约等于六年的 CPU 时间。
他们大概是开源项目中 GitHub Actions 最大的用户之一。随着 Rust 支持的平台越来越多，这个数字只会继续增长。而且平台只增不减，五年、十年后的规模会是什么样子？这是 Infra Team 必须提前思考的问题。
RISC-V 和 IBM 的请求，打开了一个新问题
目前，Rust 的 CI 完全跑在 GitHub Actions 上，依赖云服务商提供的虚拟机。但有些平台根本没有云端支持，比如 IBM 的大型机平台和 RISC-V。
最近，有公司主动找到 Infra Team，愿意提供物理硬件来参与 CI 测试。这听起来是好事，但背后的问题随之而来：
- 如果某台硬件突然不可用，PR 测试随机失败怎么办？每天能合并的 PR 数量本来就有限，加入不稳定因素会直接拖慢贡献速度。
- 更关键的是安全问题------如果要在外部硬件上构建 Tier 1 的发布产物，怎么保证没有后门被悄悄塞进去？
这些问题目前没有答案。这是 JD 在访谈中多次坦承的一点：Rust 的成长速度，已经超过了团队预先设计答案的速度。
Crater：一个跑遍全网 Rust 代码的工具
Crater 可能是 Rust 生态里最不为普通开发者所知，却极其重要的工具之一。
每当有人对 Rust 编译器提交 PR，就可以触发一次 Crater 实验。Crater 会用这个 PR 构建出的编译器，去编译 crates.io 上约 60% 的 crate，然后报告有没有出现回归问题------也就是"你的改动有没有把现有代码搞坏"。
这是 Rust 能做到强向后兼容承诺的底气之一。编译器团队在做决策时，能看到真实数据：新特性会在哪些地方引发问题，影响范围有多大。
JD 提到，这个工具让"Python 2 到 Python 3 那样的大版本迁移阵痛"更难在 Rust 身上重演------当然，这也离不开编译器团队在设计上的刻意坚守。
流量在指数级增长，但团队只有两个全职
三年前，JD 是 Infra Team 历史上第一位全职工程师------在此之前，整个基础设施都由志愿者维护，运行了十到十二年。
去年，Marco 加入，成为第二位全职成员。整个团队大约八个人，其余都是志愿者。
与此同时，crates.io 的下载量在以每年翻倍的速度增长。JD 的一位同事喜欢追踪"下载量从零到十亿需要多久"这个指标，而这个时间正在快速缩短。
为了应对带宽问题，CDN 服务商 Fastly 通过其 Fast Forward 开源赞助计划承担了全部带宽费用。Fastly 同时也是 PyPI 的赞助商------相比之下，JD 说："我们只是大海里的一条小鱼。"
AI 爬虫带来了新的压力
2025 年的新变量是 AI 爬虫。各种爬虫为了抓取训练数据，开始大规模扫描开源生态。docs.rs 首当其冲，短时间内的流量峰值直接导致服务降级。
crates.io 方面，Infra Team 提前做了架构调整，让 crate 文件的下载请求绕过应用层，直接打到 CDN，避免了类似 DDoS 的冲击。
现在他们正在讨论把 docs.rs 也迁移到 Fastly，利用其 bot 防护功能来过滤爬虫流量。这件事在年初完全不在计划里，但形势变化太快，优先级已经被迫重排。
供应链安全：Rust 正在成为攻击目标
xz-utils 后门事件让整个开源社区警觉。JD 对此谈得相当坦诚。
他说，那个事件最令人不安的地方，不是技术手段本身，而是攻击者愿意花一年半时间在一个开源项目里慢慢建立信任，然后利用这份信任植入后门。
这对 Rust 来说并非杞人忧天。Rust 项目一直在呼吁更多人参与贡献，欢迎新成员，但同时也意味着------如果有人带着恶意长期潜伏，项目本身的开放文化会成为弱点。
更现实的背景是：Rust 现在已经进入 Windows 内核、Android、iOS，以及汽车（Rivian 在本届 RustConf 上做了专题分享）乃至航天领域。用 JD 的话说，"如果你想攻击'无处不在'，那么 Rust 就成了一个有吸引力的目标。"
目前 Rust 基金会有专职安全工程师负责威胁建模，Crater 等工具也在构建沙箱隔离机制，防止构建恶意 crate 时代码逃逸到宿主机。但 JD 承认，这是一个没有完整答案的问题，整个社区还在摸索中。
所有包管理生态都在面对同一个问题
JD 提到，不同语言生态的基础设施团队之间的交流越来越多。大家发现面临的问题高度相似------"说到底，我们都只是在往互联网上传文件，不管是 npm 包还是 crate，本质上都是一堆打包好的文本文件。"
PyPI 的带宽曲线提供了一个有趣的参照：Python 的下载量长期保持平稳增长，然后在两年前突然出现曲棍球棒式的飞跃------原因是有人发现 PyPI 是个很好的模型分发渠道，而当时没有文件大小限制，于是 GPU 模型开始被上传到 PyPI。
这个教训让各个包管理生态都在重新审视自己的规则边界，以及如何在开放性和可持续性之间找到平衡。
Rust 还很年轻，而这既是挑战也是机会
访谈最后，JD 表达了他的乐观：Rust 作为稳定语言才走过约十年，而 Python 已经超过二十五岁。很多问题，Python 和 npm 用十几年才慢慢碰到，Rust 要在更短的时间里面对------但同时，Rust 也没有那十几年积累下来的历史包袱和技术债务。
他说，这让 Rust 有机会站在前沿，去定义一个"21 世纪的开源基础设施"应该是什么样的。
如果你在用 Rust，可以做什么
JD 在最后提到两件事：
一是如果你所在的公司在使用 Rust，可以考虑加入 Rust 基金会成为会员。这是支持全职工程师继续工作和填补基础设施赞助缺口的最直接方式。
二是如果你个人想贡献，Infra Team 有不少基于 Rust 编写的 bot 和工具，相对容易上手，也欢迎志愿者参与。
那些你每天不假思索敲下的 cargo 命令，背后有人在维系着这一切。