Rust 1.98.1 修复了什么哪些项目需要升级

Rust 1.98.1 不是功能型大版本，而是针对 Rust 1.98.0 编译器缺陷的点版本。官方说明指出，1.98.0 在特定条件下会生成错误的 trait object vtable：本应放函数指针的位置变成空指针，最终代码可能在间接调用时触发段错误或其他未定义行为。已经用 1.98.0 编译生产程序的团队，应把 1.98.1 作为优先升级版本；仍在 1.97.x 的项目不用为了这个问题临时重写业务代码。

Rust 1.98.1 修复的是哪一类问题

这次修复落在“编译器把正确源码翻译成了错误机器码”这一层。trait object 运行时要通过 vtable 找到具体方法，vtable 通常包含析构、布局信息和方法入口。Rust 官方发布说明给出的风险是：Rust 1.98.0 可能把某个方法入口生成为空指针；代码进入动态分发后，轻则在地址 0 处崩溃，重则落入未定义行为，不能按普通业务 panic 来处理。

这并不表示所有使用 trait 的项目都会复现。问题需要特定的泛型约束、动态分发和编译器单态化路径共同出现，项目本身可能完全没有不安全代码。也正因为错误发生在生成的 vtable 中，单靠审查业务源码很难排除，升级编译器比围绕某个调用点打补丁更稳妥。

哪些项目应该优先升级到 1.98.1

先看构建器，而不是先看项目名字。下面三项同时出现时，优先级最高：

反过来，仍固定在 Rust 1.97.x 的项目，没有必要为了这条公告立即改变 trait 设计。但要检查 CI 是否写成了模糊的 stable，否则下一次无意间切到 1.98.0，复现条件可能被带入构建链。已经发布的旧二进制也不会因为安装 1.98.1 自动改变，必须重新编译并替换制品。

升级时怎么选工具链和验证范围

使用 rustup 的机器可以先更新 stable：

# 更新 stable 通道，随后确认当前 shell 实际使用的编译器
rustup update stable
rustc --version

# 在项目目录确认 rustup 覆盖配置没有把构建锁回旧版本
rustup show active-toolchain

如果项目使用 rust-toolchain.toml 或 CI 镜像固定版本，应同步修改固定值，而不是只在开发机执行更新。检查结果至少要包含 rustc --version、目标三元组、依赖锁文件和构建镜像标签；否则“我已经升级”只说明一台机器升级了。

回归测试也不要只跑单元测试。把使用动态 trait 的服务启动、正常请求、上游失败、连接升级和跨平台构建放进一次构建矩阵。官方关联 issue 中，某个基于 boxed async service 的示例在 1.98.0 下出现空地址崩溃，而 1.97.1 和稍后的 nightly 没有复现；这说明测试应覆盖间接调用真正发生的路径，而不只是检查 crate 能否编译。

临时 workaround 能不能代替升级

关联 issue 中展示过把复杂的泛型服务调用移到显式函数指针或闭包擦除边界的 workaround，它可以帮助项目在无法立刻升级时恢复构建或运行，但不应被当成这次缺陷的普遍修复。临时改动会扩大类型擦除范围，增加维护成本，也可能只避开一个触发形态。

更合理的顺序是：先固定并升级到 1.98.1，再用原有测试确认问题消失；只有确实受发布窗口、交叉编译环境或供应链镜像限制的项目，才保留最小 workaround，并记录移除条件。不要为了“验证升级”继续把同一个 1.98.0 二进制发布到生产。

常见问题

Rust 1.98.1 是安全漏洞修复吗？

官方公告将其描述为 rustc 的错误编译修复。它可能导致未定义行为，风险表现类似严重稳定性问题，但不能据此自行扩大成某个通用 CVE 结论。

只使用静态分发的项目需要立刻升级吗？

如果项目确实没有经过 trait object 或相关动态擦除路径，紧急程度较低；但若构建器已是 1.98.0，升级点版本通常比长期停留在缺陷版本更简单。

执行 rustup update stable 后为什么版本没变？

常见原因是项目目录被 rust-toolchain.toml 覆盖，或 CI 使用独立容器镜像。分别查看 rustup show active-toolchain 和 CI 日志，确认实际 rustc 路径与版本。

Rust 官方发布说明：Announcing Rust 1.98.1；相关复现讨论：rustc emits a vacant vtable slot。升级完成的判据不是安装命令返回成功，而是新版本重新产出制品，并通过动态分发路径的回归测试。