필사 모드: Rust 1.97.0 发布了 — 我正好在用那个 cargo 构建 Kubernetes Operator

• 引言 — 发布说明与我的终端交汇的那天
• 1.97 中实际发生变化的三件事
• 说句实话 — 对 Operator 而言，kube-rs 比工具链版本更重要
• 那么，谁现在该升级
• 结语
• 参考资料

引言 — 发布说明与我的终端交汇的那天

2026 年 7 月 9 日，Rust 1.97.0 作为 stable 发布了。凑巧的是，就在那几天前，我一直在家庭实验室的服务器（Ubuntu，用 rustup 安装）上用 cargo 1.97 编写 Kubernetes GPU Operator。所以这篇文章有两层 —（1）照实读一读发布说明里 真正变了的东西，（2）以一个正好用那套工具链做过实际工作的人的视角，诚实地追问「它到底改变了我的工作什么」。先把结论摆出来：这不是一个让人兴奋的版本。而这并不是贬义。

1.97 中实际发生变化的三件事

发布说明里的重点有三个。三个都不是语言语法，而是关于 工具链的行为。

1. v0 符号修饰（symbol mangling）成为 stable 默认值。 此前 rustc 一直复用 C++ 的 Itanium ABI 修饰方式，这种方式把泛型参数藏在哈希之后，丢失了信息。新的 v0 方案是 Rust 专用的，正如发布说明所说，「泛型参数的实例化不再只被追踪在哈希之后，而是保留其值」。它从 2025 年 11 月起就是 nightly 的默认值，在 1.97 中晋升为 stable。看得见的效果是回溯（backtrace）、perf 这类性能分析器以及调试器里的符号更易读 — 属于平时看不见、深挖问题时才会庆幸的那种变化。

2. Cargo 可以「拒绝（deny）」警告了。 新的 build.warnings 配置（环境变量 CARGO_BUILD_WARNINGS）给出三档 — allow（忽略）、warn（构建通过，默认值）、deny（有警告即构建失败）。

# .cargo/config.toml
[build]
warnings = "deny"

核心好处正如发布说明所说，「用了这个功能也不会让构建缓存失效」。此前 CI 里常用的 RUSTFLAGS="-D warnings" 一旦标志改变就会触发全量重新构建，而这个不会，所以临时开关很方便。在 CI 里与 --keep-going 组合，还能在停下之前把所有错误都收集起来一起看。

3. 链接器输出不再被隐藏。 此前只要链接成功，rustc 就会悄悄吞掉链接器输出。从 1.97 起，链接器消息会作为警告级别的 lint 默认显示，并通过 Cargo.toml 的 [lints.rust] 来调节。据说在 nightly 上把它打开后，确实暴露出几个此前隐藏的缺陷并得到了修复。

还有一些琐碎的稳定化 API。

Default for RepeatN
Copy   for ffi::FromBytesUntilNulError
Send   for std::fs::File (UEFI)
<{integer}>::isolate_highest_one / isolate_lowest_one / highest_one / lowest_one
<{uN}>::bit_width
NonZero<{integer}>:: 上述方法的对应版本
const 提升: char::is_control

如果是直接操作比特位的代码，这些整数方法会很受欢迎，但对大多数应用代码来说，今天并不会立刻产生影响。

说句实话 — 对 Operator 而言，kube-rs 比工具链版本更重要

这才是本文真正的要点。我用 cargo 1.97 构建并运行了一个真实的 Operator。这是实测环境。

构建   cargo 1.97, release 首次 16.7 秒（含依赖），增量 2.6 秒
crate  kube 0.96 (client+runtime+derive+rustls-tls), k8s-openapi 0.23 (v1_31)
运行   out-of-cluster，用 ~/.kube/config 连接真实 API 服务器
目标   Kubernetes v1.32.5

但说实话，上面这三个 1.97 的重点，没有一个改变了我写这个 Operator 的方式。 让 Operator 成为可能的，不是语言或工具链的这个版本，而是 kube-rs 0.96 这个生态 — 用 #[derive(CustomResource)] 把结构体变成 CRD，controller 运行时驱动 reconcile 循环，rustls-tls 让它不依赖 openssl 就能在任何地方构建。这些杠杆全都在 crate 那一侧。

16.7 秒／2.6 秒这样的构建速度，与其说是 1.97 的功劳，不如说只是 cargo 一如既往地是 cargo。也就是说，Rust 的 语言与工具链已经稳定到无聊的程度（这是褒义），真正的生产力差距出在生态上。那个 Operator 实际发现了什么 — 我的 4 个 GPU 节点全都挂了这个诊断 — 我连同实测日志另外整理在了用 Rust 打造 Kubernetes GPU Operator里。

那么，谁现在该升级

平心而论，可以这样归纳。

• 大多数人：直接 rustup update stable 然后忘掉它就行。没有理由改动代码。
• 经常调试、做性能分析的人：多亏 v0 修饰，回溯和 perf 符号会变好。是安静但实在的收益。
• 管理 CI 的人：build.warnings = "deny" 不破坏缓存就能把警告变成失败，值得用来替代 RUSTFLAGS="-D warnings"。
• 和交叉编译、自定义链接器较劲的人：现在能看到链接器一直在说什么了。对深挖问题的人来说是个可喜的变化。

$ rustup update stable

没有理由着急。就像六周一次的安静发布那样，升上去大体会好一些，不升今天也不会立刻坏掉。

结语

诚实的感想是这样。Rust 1.97 不是撼动语法的版本，而是打理符号、警告、链接器这类 工具链卫生 的版本。它并不华丽，但正是这些东西一点点累积，才铸成了「只要能跑起来大体就是对的」这份对语言的信任。而那几天的实测教给我的，是一个略微不同的角度 — 推动实际工作的力量，不在工具链的版本号上，而在其之上成熟起来的生态（kube-rs）里。所以 1.97 就静静地升上去，把精力用在挑选 crate 上更好。

参考资料

• Announcing Rust 1.97.0（官方发布说明）
• 用 Rust 打造 Kubernetes GPU Operator — 本文的实测搭档
• kube-rs — 官方网站与文档