rust 1.97.0最新发布全解析：语言、Cargo、Rustdoc、平台支持与兼容性变化一次看懂

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

2026年7月11日，rust 1.97.0 正式发布。 这次更新覆盖语言层、平台支持、标准库稳定化 API、Cargo、Rustdoc，以及一系列需要重点关注的兼容性说明。对于正在维护工程、升级工具链、观察 lint 变化、关注目标平台能力，或者依赖底层行为稳定性的开发者来说，1.97.0 的变化非常集中，也非常值得逐条梳理。

一、rust 1.97.0 发布信息概览

本次版本信息如下：

• • 版本号：1.97.0
• • 发布时间：2026年7月11日

从更新列表来看，这一版并不是只做少量修补，而是在多个层面同步推进：

• • 语言特性和 lint 规则继续细化
• • 若干 target feature 正式稳定
• • 原子相关条件编译能力增强
• • 导入语法适用范围扩大
• • 平台支持中对 CUDA 架构和 ISA 进行清理
• • 标准库新增一批整数与 NonZero 相关稳定 API
• • Cargo 增加更适合 CI 和只读目录工作流的能力
• • Rustdoc 两个常用参数稳定
• • 兼容性与行为变化较多，需要升级前重点阅读

如果说一个版本是否“值得升级”，往往要看它是否同时影响日常开发、构建系统、文档系统和底层兼容性，那么 rust 1.97.0 显然属于这样一个版本。

二、语言层更新：lint、target feature、cfg 与导入语法都有变化

本次语言部分的更新包括以下几项：

• • Consider Result<T, Uninhabited> and ControlFlow<Uninhabited, T> to be equivalent to T for must use lint
• • Add allow-by-default dead_code_pub_in_binary lint for unused pub items in binary crates
• • Stabilize the div32, lam-bh, lamcas, ld-seq-sa and scq target features
• • Stabilize cfg(target_has_atomic_primitive_alignment)
• • Allow trailing self in imports in more cases

下面逐项来看。

1、must use lint 对 Result<T, Uninhabited> 与 ControlFlow<Uninhabited, T> 的等价处理

rust 1.97.0 将以下两种类型在 must use lint 的语义上视为等价于 T：

• • Result<T, Uninhabited>
• • ControlFlow<Uninhabited, T>

这意味着，当错误分支或中断分支本质上不可构造时，这两类包装类型在 must use 检查上的处理会更贴近它们实际表达的语义，也就是更接近“只是一个 T”。这一变化直接作用于 lint 行为，核心是让 must use 的判断更加符合类型真实可达性。

这一点虽然看起来细，但它影响的是编译器对“值是否必须被使用”的理解方式。对于使用不可居住类型来建模不可能分支的代码来说，lint 行为会因此更一致。

2、新增 dead_code_pub_in_binary lint，默认允许

新增一个 lint：

• • dead_code_pub_in_binary

它用于检查 binary crate 中未使用的 pub 项。 同时，这个 lint 的默认级别是 allow-by-default，也就是默认允许。

这个变化的重点不在“立即变严格”，而在于编译器已经把这个问题独立识别出来：在二进制 crate 中，一些标记为 pub 的项实际上并不会被外部 crate 当作公共 API 使用，因此它们是否未使用，应该有更准确的提示维度。

默认允许说明这一 lint 当前更偏向可选治理能力，而不是直接改变大量现有项目的编译体验。对于想收紧代码质量规则的项目，可以关注这一 lint 的实际使用场景。

3、稳定若干 target feature

本次稳定的 target feature 包括：

• • div32
• • lam-bh
• • lamcas
• • ld-seq-sa
• • scq

target feature 的稳定意味着与这些能力相关的目标平台特性可以进入稳定 Rust 的使用范围。对特定平台、特定底层优化路径、特定硬件能力适配有要求的场景来说，这类稳定化非常关键，因为它意味着工具链层面对这些能力的支持更加正式。

4、稳定 cfg(target_has_atomic_primitive_alignment)

本次还稳定了：

• • cfg(target_has_atomic_primitive_alignment)

这是一个条件编译相关能力。稳定后，开发者可以基于目标平台是否具备 atomic primitive alignment 进行更明确的 cfg 判断。 对于涉及原子操作、平台能力差异、底层并发实现或条件编译分支控制的代码来说，这一条件项稳定后可用性更高。

5、允许在更多情况下在 imports 中使用 trailing self

本次还放宽了导入语法规则：

• • Allow trailing self in imports in more cases

也就是说，在更多导入场景中，trailing self 的写法将被接受。 这是语法适用范围上的扩大，直接提升的是导入书写的一致性和灵活性。

三、平台支持变化：nvptx64-nvidia-cuda 清理旧架构与旧 ISA

本次平台支持部分给出的信息是：

• • nvptx64-nvidia-cuda: drop support for old architectures and old ISAs
• • Refer to Rust's platform support page for more information on Rust's tiered platform support.

这里的核心变化很明确：

• • 对 nvptx64-nvidia-cuda，移除了对旧架构和旧 ISA 的支持

这意味着，对于依赖这一目标平台的场景，如果仍然建立在较旧的架构或较旧 ISA 基础之上，就需要特别注意升级影响。 从平台支持治理的角度看，这类变化通常意味着工具链在逐步收敛支持范围，把维护重点放到仍然被支持的架构和 ISA 上。

同时，发布说明提醒可参考平台支持页面，以了解 Rust 分层平台支持的更多信息。这个提示本身也是一个信号：平台支持并不是静态不变的，升级工具链时，目标平台状态需要同步确认。

四、稳定化 API：标准库新增多项稳定能力

本次稳定 API 列表如下：

• • Default for RepeatN
• • Copy for ffi::FromBytesUntilNulError
• • Send for std::fs::File on UEFI
• • <{integer}>::isolate_highest_one
• • <{integer}>::isolate_lowest_one
• • <{integer}>::highest_one
• • <{integer}>::lowest_one
• • <{integer}>::bit_width
• • NonZero<{integer}>::isolate_highest_one
• • NonZero<{integer}>::isolate_lowest_one
• • NonZero<{integer}>::highest_one
• • NonZero<{integer}>::lowest_one
• • NonZero<{integer}>::bit_width

此外，还有一项“此前已经稳定，但现在在 const 上下文中也稳定”的能力：

• • char::is_control

下面分别梳理。

1、RepeatN 现在实现 Default

• • Default for RepeatN

这代表 RepeatN 新增了 Default 能力。 对于依赖默认构造模式的代码来说，这使得 RepeatN 在某些泛型、容器初始化、默认实例组合场景中更容易使用。

2、ffi::FromBytesUntilNulError 现在实现 Copy

• • Copy for ffi::FromBytesUntilNulError

这一变化意味着该错误类型现在具备 Copy 语义。 对需要轻量传递、复制错误值的代码来说，这会带来更直接的使用方式。

3、UEFI 上的 std::fs::File 现在实现 Send

• • Send for std::fs::File on UEFI

这是一项平台相关的 trait 能力补充。 其含义非常直接：在 UEFI 平台上，std::fs::File 现在具备 Send。 这会影响与线程边界、所有权转移、并发使用模型相关的代码能力判断。

4、整数类型新增多项位操作相关稳定 API

本次稳定的一组整数 API 包括：

• • <{integer}>::isolate_highest_one
• • <{integer}>::isolate_lowest_one
• • <{integer}>::highest_one
• • <{integer}>::lowest_one
• • <{integer}>::bit_width

从命名就能看出，这一组 API 围绕整数位级信息展开，覆盖：

• • 最高位的 1 的隔离
• • 最低位的 1 的隔离
• • 最高位的 1
• • 最低位的 1
• • 位宽

这意味着，在整数位运算、位分析、掩码处理等场景下，稳定标准库进一步补足了直接可用的能力。

5、NonZero 整数类型也新增对应稳定 API

与普通整数对应，本次还稳定了 NonZero<{integer}> 上的同类 API：

• • NonZero<{integer}>::isolate_highest_one
• • NonZero<{integer}>::isolate_lowest_one
• • NonZero<{integer}>::highest_one
• • NonZero<{integer}>::lowest_one
• • NonZero<{integer}>::bit_width

这说明标准库并不是只给普通整数提供位能力，而是同步扩展到了 NonZero 整数体系。 对于大量使用 NonZero 进行优化表达、空间优化或语义建模的代码来说，这种成套提供能力的方式更完整，也更一致。

6、char::is_control 现在可用于 const 上下文

发布说明中特别指出：

• • These previously stable APIs are now stable in const contexts:
• • char::is_control

也就是说，char::is_control 此前已经是稳定 API，但在 rust 1.97.0 中，它进一步在 const 上下文中稳定。 这意味着相关字符控制属性判断可在编译期常量语境中使用。

五、Cargo 更新：CI、锁文件路径、清理保护与命令简写都有变化

本次 Cargo 更新包括：

• • Stabilize build.warnings config. This controls how lint warnings from local packages are treated. Useful for enforcing a warning-free build in CI, replacing -Dwarnings.
• • Stabilize resolver.lockfile-path config. This allows specifying the path to the lockfile to use when resolving dependencies. Useful when working with read-only source directories.
• • cargo-clean: Error when --target-dir doesn't look like a Cargo target directory. This prevents accidental deletion of non-target directories.
• • Add -m shorthand for --manifest-path
• • Remove curl dependency from crates-io crate

这些变化分布在构建控制、依赖解析、目录安全检查、命令体验以及内部依赖调整等多个方面。

1、build.warnings 配置稳定

• • Stabilize build.warnings config

这一配置用于控制：

• • how lint warnings from local packages are treated

发布说明还特别强调了它的用途：

• • Useful for enforcing a warning-free build in CI, replacing -Dwarnings.

也就是说，build.warnings 配置稳定之后，Cargo 在处理本地包 lint warning 方面有了正式配置手段。 对 CI 来说，这个能力很实用，因为它可以用来强制实现“无 warning 构建”，并作为替代方式取代 -Dwarnings。

这条更新的重点有两个：

• • 它控制的是本地包产生的 lint warning 的处理方式
• • 它非常适合 CI 中的无警告构建要求

2、resolver.lockfile-path 配置稳定

• • Stabilize resolver.lockfile-path config

这一配置允许：

• • specifying the path to the lockfile to use when resolving dependencies

发布说明给出的典型使用场景是：

• • Useful when working with read-only source directories.

也就是说，在依赖解析时，现在可以指定所使用的 lockfile 路径。 对于只读源码目录场景，这一点非常关键，因为它提供了更灵活的 lockfile 使用方式。

这类能力对受限环境、特殊工作区布局、不可写源码挂载等场景都有直接价值。

3、cargo clean 在 --target-dir 不像 Cargo target 目录时会报错

• • cargo-clean: Error when --target-dir doesn't look like a Cargo target directory.

发布说明同时说明其目的：

• • This prevents accidental deletion of non-target directories.

这个变化非常直观： 如果传入的 --target-dir 看起来不像 Cargo 的 target 目录，cargo clean 现在会直接报错，而不是继续执行清理。

这样做的意义只有一个，但非常重要：

• • 防止误删非 target 目录

对于脚本化构建、动态路径拼接、CI 环境变量配置错误等情况，这是很有价值的保护。

4、新增 -m 作为 --manifest-path 的简写

• • Add -m shorthand for --manifest-path

这是一个命令行体验优化。 以后在需要指定 manifest 路径时，可以直接使用 -m，更简洁。

5、从 crates-io crate 中移除 curl 依赖

• • Remove curl dependency from crates-io crate

这是一项依赖层面的调整。 发布说明没有展开更多细节，但该项已经明确列入 Cargo 更新内容中。

六、Rustdoc 更新：两个常用参数稳定

本次 Rustdoc 的更新内容为：

• • Stabilize --emit flag
• • Stabilize --remap-path-prefix

这两项都是命令参数层面的稳定化。

1、--emit 稳定

• • Stabilize --emit flag

说明 Rustdoc 的 --emit 选项现在正式稳定。

2、--remap-path-prefix 稳定

• • Stabilize --remap-path-prefix

说明 Rustdoc 的 --remap-path-prefix 选项也正式稳定。

对于文档生成、路径处理、构建输出控制等流程而言，这两项参数稳定后，可在稳定工具链上更正式地使用。

七、兼容性说明：这一部分是升级 1.97.0 前最需要认真阅读的内容

本次 Compatibility Notes 非常多，涉及类型推断、符号改编、宏行为、弃用、链接、枚举编码、属性校验、Windows socket 错误映射等多个维度。下面逐项整理。

原始列表包括：

• • Emit a future-compatibility warning when relying on f32: From<{float}> to constrain {float}
• • Rust will use the v0 symbol mangling scheme by default. This may cause some tools (such as debuggers or profilers, especially with old versions) to fail to demangle symbols emitted by Rust. It may also cause the formatting of text in backtraces to change.
• • Prevent deref coercions in pin!, in order to prevent unsoundness. The most likely case where this might impact users is: writing pin!(x) where x has type &mut T will now always correctly produce a value of type Pin<&mut &mut T>, instead of sometimes allowing a coercion that produces a value of type Pin<&mut T>. This coercion was previously incorrectly allowed since Rust 1.88.0.
• • Deprecate std::char constants and functions
• • Warn on linker output by default
• • Remove hidden f64 methods which have been deprecated since 1.0
• • report the varargs_without_pattern lint in deps
• • Forbid passing generic arguments to module path segments even if the module reexports a generic enum variant
• • Error on invalid macho link_section specifier
• • The encoding of certain enums have changed. This is not a breaking change, as it only applies to enums without layout guarantees, but is noted here as we've seen people impacted from having made assumptions about the layout algorithm.
• • Error on #[export_name = "..."] where the name is empty
• • Syntactically reject tuple index shorthands in struct patterns
• • validate #[link_name = "..."] and #[link(name = "...")] parameters
• • On Windows, after calling shutdown on a socket to shut down the write side, attempting to write to the socket will now produce a BrokenPipe error rather than Other. Map WSAESHUTDOWN to io::ErrorKind::BrokenPipe

下面逐项展开。

1、对依赖 f32: From<{float}> 来约束 {float} 的情况发出 future-compatibility warning

• • Emit a future-compatibility warning when relying on f32: From<{float}> to constrain {float}

这说明：如果代码依赖 f32: From<{float}> 这一点来约束 {float}，现在将收到 future-compatibility warning。 重点在于“future-compatibility warning”，也就是这类写法未来兼容性存在风险，因此编译器开始提前提示。

2、默认使用 v0 symbol mangling scheme

• • Rust will use the v0 symbol mangling scheme by default.

这是一个非常关键的底层变化。 从 rust 1.97.0 开始，Rust 默认使用 v0 符号改编方案。

发布说明明确指出可能带来的影响：

• • 一些工具，尤其是旧版本的调试器或性能分析工具，可能无法对 Rust 生成的符号正确解码
• • 回溯信息中文本格式可能发生变化

也就是说，这并非简单的内部实现调整，它可能会直接影响：

• • debugger 的符号解码
• • profiler 的符号解码
• • backtrace 的显示文本格式

特别是老版本工具，受到影响的可能性更高。

3、pin! 中禁止 deref coercions，以防止不健全性

• • Prevent deref coercions in pin!, in order to prevent unsoundness.

发布说明给出的最可能影响用户的场景是：

• • 写 pin!(x)，其中 x 的类型是 &mut T

现在的行为变为：

• • 总是正确地产生 Pin<&mut &mut T>

而不是此前有时会错误允许的行为：

• • 通过 coercion 产生 Pin<&mut T>

说明还指出：

• • 这一 coercion 自 rust 1.88.0 起就被错误地允许了

这是一次明确的正确性修复，目标是防止 unsoundness。 因此，如果现有代码曾依赖 pin! 中这种错误放行的 deref coercion，升级后就需要注意行为变化。

4、弃用 std::char 常量和函数

• • Deprecate std::char constants and functions

这是一项弃用变更。 发布说明没有扩展更多内容，但含义明确：std::char 中的常量与函数进入弃用状态。

5、默认对 linker output 发出 warning

• • Warn on linker output by default

也就是说，linker output 现在默认会触发 warning。 这会影响构建日志表现，也意味着链接器输出不再是默认静默忽略的状态。

6、移除自 1.0 起就已弃用的隐藏 f64 方法

• • Remove hidden f64 methods which have been deprecated since 1.0

这里强调了两个点：

• • 这些 f64 方法是 hidden 的
• • 它们自 1.0 起就已经被弃用

在 rust 1.97.0 中，这些方法被移除。

7、在依赖中报告 varargs_without_pattern lint

• • report the varargs_without_pattern lint in deps

这意味着 varargs_without_pattern lint 现在会在依赖中报告。 其影响范围从当前包视角扩展到了 deps。

8、即便模块重新导出了泛型枚举变体，也禁止向模块路径段传递泛型参数

• • Forbid passing generic arguments to module path segments even if the module reexports a generic enum variant

这是语法与路径解析约束的收紧。 重点在于：即使模块重新导出了泛型枚举变体，也不允许把泛型参数传给模块路径段。

9、对无效的 macho link_section specifier 报错

• • Error on invalid macho link_section specifier

这说明，在 Mach-O 相关场景中，如果 link_section specifier 无效，将直接报错。 这是校验行为的明确收紧。

10、某些枚举的编码已发生变化

• • The encoding of certain enums have changed.

发布说明同时特别说明：

• • 这不是破坏性变更
• • 它只适用于没有 layout guarantees 的枚举
• • 之所以特别注明，是因为已经看到有人对布局算法做了假设并受到影响

这条兼容性说明非常值得注意。 虽然官方明确表示这不属于 breaking change，但如果代码、工具或者外部系统曾经对“无布局保证枚举”的编码或布局算法做出假设，那么升级后可能观察到变化。

核心信息可以概括为三点：

• • 某些枚举编码变了
• • 这些枚举本身没有布局保证
• • 假设布局算法的代码可能受到影响

11、当 #[export_name = "..."] 的名字为空时直接报错

• • Error on #[export_name = "..."] where the name is empty

也就是说，如果 export_name 指定为空字符串，现在会报错。

12、在结构体模式中，语法上拒绝 tuple index shorthand

• • Syntactically reject tuple index shorthands in struct patterns

这是一项语法拒绝规则。 在 struct patterns 中，tuple index shorthand 现在会被直接从语法层面拒绝。

13、校验 #[link_name = "..."] 与 #[link(name = "...")] 参数

• • validate #[link_name = "..."] and #[link(name = "...")] parameters

这说明编译器现在会对这两个属性中的参数进行校验。 这属于属性参数验证层面的加强。

14、Windows 上 socket shutdown 写侧后，再写入将从 Other 变为 BrokenPipe

• • On Windows, after calling shutdown on a socket to shut down the write side, attempting to write to the socket will now produce a BrokenPipe error rather than Other.
• • Map WSAESHUTDOWN to io::ErrorKind::BrokenPipe

这是一项平台行为变化，而且描述得很具体。

在 Windows 上：

• • 如果对 socket 调用 shutdown 来关闭写侧
• • 然后再尝试向该 socket 写入

现在得到的错误将是：

• • BrokenPipe

而不是此前的：

• • Other

根本原因也已明确：

• • 将 WSAESHUTDOWN 映射到 io::ErrorKind::BrokenPipe

对于依赖错误种类判断的 Windows 网络代码来说，这一点需要特别注意，因为错误分类已经变了。

八、rust 1.97.0 这次更新的完整重点回顾

为了便于快速浏览，可以把这次版本更新压缩成以下总览：

语言方面

• • must use lint 视 Result<T, Uninhabited> 和 ControlFlow<Uninhabited, T> 为等价于 T
• • 新增默认允许的 dead_code_pub_in_binary lint，用于 binary crate 中未使用的 pub 项
• • 稳定 div32、lam-bh、lamcas、ld-seq-sa、scq target features
• • 稳定 cfg(target_has_atomic_primitive_alignment)
• • 在更多导入场景中允许 trailing self

平台支持方面

• • nvptx64-nvidia-cuda 移除对旧架构和旧 ISA 的支持

稳定 API 方面

• • RepeatN 实现 Default
• • ffi::FromBytesUntilNulError 实现 Copy
• • UEFI 上 std::fs::File 实现 Send
• • 整数类型新增 isolate_highest_one、isolate_lowest_one、highest_one、lowest_one、bit_width
• • NonZero<{integer}> 新增同名能力
• • char::is_control 在 const 上下文中稳定

Cargo 方面

• • 稳定 build.warnings
• • 稳定 resolver.lockfile-path
• • cargo clean 在可疑 --target-dir 情况下报错，防止误删
• • 新增 -m 作为 --manifest-path 简写
• • 从 crates-io crate 移除 curl 依赖

Rustdoc 方面

• • 稳定 --emit
• • 稳定 --remap-path-prefix

兼容性方面

• • 对依赖 f32: From<{float}> 约束 {float} 的写法发出 future-compatibility warning
• • 默认启用 v0 symbol mangling
• • pin! 中阻止 deref coercions，修复不健全性
• • 弃用 std::char 常量与函数
• • 默认对 linker output 发 warning
• • 移除自 1.0 起已弃用的隐藏 f64 方法
• • 在依赖中报告 varargs_without_pattern lint
• • 禁止向模块路径段传递泛型参数，即使其重导出了泛型枚举变体
• • 无效的 macho link_section specifier 现在报错
• • 某些无布局保证的枚举编码发生变化
• • #[export_name = "..."] 为空时报错
• • 在 struct patterns 中语法拒绝 tuple index shorthand
• • 校验 #[link_name = "..."] 和 #[link(name = "...")] 参数
• • Windows 上 socket 写侧 shutdown 后再写入，将得到 BrokenPipe 而不是 Other

九、总结

代码地址：github.com/rust-lang/rust

rust 1.97.0 是一次覆盖面很广的更新。 它不仅带来了标准库 API 的稳定化，也继续完善了 lint 行为、目标平台能力、Cargo 配置和 Rustdoc 参数；同时，在兼容性说明中给出了大量值得升级前检查的行为变化。

如果只看表面，这一版似乎有很多“细节项”；但如果从工程维护角度看，恰恰是这些细节项最容易影响真实项目：

• • lint 是否更准确
• • target feature 是否能在稳定版使用
• • cfg 判断是否更完善
• • Cargo 是否适合 CI 与只读目录
• • Rustdoc 是否更易集成
• • 底层符号改编、链接行为、属性校验、宏行为与平台错误映射是否改变

因此，rust 1.97.0 的价值，不只是“新增了什么”，更在于它对稳定工具链生态的进一步收紧、完善与统一。

·

我们相信人工智能为普通人提供了一种“增强工具”，并致力于分享全方位的AI知识。在这里，您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。

·