Rust 1.90 edition 迁移怎样判断影响

判断 Rust 1.90 下的 edition 迁移影响，应先把两件事分开：升级 rustc/Cargo，不会自动把已有项目切换到新 edition；切换 edition 则需要修改项目清单并处理兼容性差异。Rust 2024 已在 1.85.0 引入，1.90 不是一个名为“edition 1.90”的新版本。

官方地址：https://www.rust-lang.org/

我会先保留旧 edition，建立能比较的基线

面对这种升级，我倾向于先保留 Cargo.toml 的现有 edition 和依赖锁定结果，只替换工具链。这是为了让后续差异容易归因的工程建议，不是一份已经跑过的项目迁移报告。本文没有实测构建耗时或性能数字。

建议在记录表中保留当前工具链、edition、目标平台、启用的 features、构建结果、测试失败项及耗时口径。下面三种状态比“升级前/后”两个标签更清楚：

A 与 B 应保持依赖选择一致；B 与 C 则应单独记录迁移修复的源码和清单改动。若必须升级某个宏依赖，我会把它另作一次变更，先确认依赖升级本身的影响。

为什么编译变快，也不能算 edition 的收益？

Rust 1.90 官方公告的重要变化之一，是 x86_64-unknown-linux-gnu 默认链接器改用 LLD。因而只比较升级前后总构建时间，可能把链接器差异误认为 edition 的效果。该变化有明确目标平台范围，不能照搬到所有系统。

对我来说，比“快了多少”更有用的第一条记录是：差异出现于检查、编译、链接还是运行阶段。性能比较应固定目标、构建模式、缓存条件和输入，多次采样；没有这些条件，单次耗时不足以支持迁移收益结论。

在旧 edition 上先运行 1.90

如果项目使用 rustup，可以显式选择历史工具链，而不是用会随时间变化的 stable 别名。这些命令供读者在迁移分支自行执行，不包含本机运行结果。工作树应先整理干净，已有失败须记录后再开始修改。

# 安装并显式选择目标工具链，不更改全局默认工具链。
rustup toolchain install 1.90.0
cargo +1.90.0 --version
rustc +1.90.0 --version

# 暂不修改 edition；--locked 阻止本次检查悄悄更新锁文件。
cargo +1.90.0 check --workspace --all-targets --locked
cargo +1.90.0 test --workspace --locked

若这一步已经失败，我会先处理工具链、依赖或平台适配，不急着改 edition。若因锁文件需要更新而停止，应明确更新原因，单独记录更新；不能为了让命令通过就把所有变化混在一次提交里。

自动迁移后，我最关注哪些改动？

以下假定原项目使用 edition 2021，并计划迁移到 2024。更早 edition 应按指南逐次迁移。先在旧 edition 下运行修复工具，再手动修改清单：

# 从干净的迁移分支开始；自动修复只能覆盖本次参与检查的代码。
cargo +1.90.0 fix --edition --workspace --locked

# 查看本次修复，特别留意资源释放及宏相关改动。
git diff

在适用的 [package] 节中，将 edition 设置为以下值；不要用这段片段覆盖现有清单。采用 workspace 继承的项目，应在实际控制该设置的位置修改。

# Rust 2024 是 edition 名称，1.90.0 是工具链版本。
edition = "2024"

例如，2024 改变了 if let 条件中临时值在进入 else 分支前的释放范围。迁移工具可能建议改成 match 来维持旧行为。我的取舍是逐处看资源持有时机是否符合业务意图，而不是只看“现在能编译”。涉及锁、文件句柄或自定义 Drop 的代码尤其值得理解这类差异。

自动修复完成不代表全部代码已覆盖。未启用的 features、不同目标的 cfg 分支，以及文档示例、构建时代码生成和宏，都可能需要额外处理。不要盲目使用 --all-features：有些项目的功能组合本来就互斥，应按实际支持组合逐项安排。

最后怎样决定是否合并迁移？

# 手动切换清单到2024之后，再检查并运行测试。
cargo +1.90.0 check --workspace --all-targets --locked
cargo +1.90.0 test --workspace --locked

# 格式化单独查看，避免掩盖语义修复。
cargo +1.90.0 fmt --all
git diff

我会把是否合并落到三类证据：相对 B 状态新增的诊断是否解释清楚，关键行为是否符合预期，支持矩阵中的目标和 features 是否有覆盖。格式化差异最好与语义修复分开记录。没有项目已有基准时，不必为了迁移文章制造一个无关压测。

如果业务正在稳定维护、没有采用新 edition 的需求，可以先保留旧 edition 并升级工具链；若要使用新规则且有能力处理迁移差异，再安排切换。这两种选择都应基于项目约束，不能仅以“版本较新”判断优劣。

依赖也必须全部切换到 2024 吗？

不必要求整个依赖树同时改 edition。应关注依赖和宏能否在目标工具链及项目配置下正常工作。

cargo fix 会修改 Cargo.toml 的 edition 吗？

不会替你完成这个切换，需要在修复后手动修改清单，再进行构建和测试。

测试通过是否就能证明迁移没有风险？

只能说明已覆盖的测试通过。未编译配置、未测目标及资源释放等业务行为，仍需按项目范围判断。

参考：Rust 1.90.0 官方公告；Rust 2024；官方 edition 迁移指南；cargo fix；if let 临时值范围变化。