Rust 1.99.0 正式发布，新特性该怎么用：新手该不该现在跟进

Rust 1.99.0 已于 2026 年 10 月 1 日发布，1.99.1 补丁在 2026 年 10 月 15 日跟进。新手真正要判断的不是"新特性怎么用"，而是三件事：你用的是稳定版还是 nightly、升级会不会因为新 lint 让你的 CI 变红、以及你的项目锁没锁工具链。本文先核对官方发布时间与本轮真实变化，再把"学习、个人项目、团队协作"三种场景分开判断，最后给一份含验证与回退的升级检查清单。文中命令结果均标注为预期结果、未在本机执行，请先在测试目录跑通。

先看结论

• 纯学习：直接装最新稳定版。 学习阶段不承担发布风险，装 1.99.x 能少遇到旧版本已知问题。
• 个人项目：可以升，但先跑一遍完整测试。 本轮有 lint 行为调整，#![deny(warnings)] 的项目最容易在升级后编译失败。
• 团队或生产项目：锁版本再升。 用 rust-toolchain.toml 固定到具体版本，先在一个分支上验证，再合并。
• 不要追 nightly。 1.100 计划于 2026-11-12 转为稳定版，nightly 上的语法随时可能变化，新手用它只会增加排查成本。

一、先核对发布日期与官方变化

动手前先把可核对的事实摆出来。第一是发布时间：官方 Rust Blog 在 2026 年 10 月 1 日发布 1.99.0，Rust Forge 的当前版本表同样标注 Stable 1.99 的稳定日期为 2026-10-01；1.99.1 于 2026-10-15 发布，属于补丁版本。第二是发布节奏：Rust 采用约六周一个稳定版的节奏，下一个版本 1.100 计划在 2026-11-12 稳定。第三是本轮真实变化，以下均来自官方发布说明（证据等级：官方文档）：

• 稳定了 C 可变参数函数定义，并允许用 #[unsafe(naked)] 定义这类函数；
• 稳定了 #[my_macro] mod foo; 写法，自定义属性或派生宏内部可以使用外置模块；
• 新增默认允许的 raw_borrows_via_references lint，检查"立刻退化成裸借用"的引用；
• unconditional_panic lint 扩展到 chunks(0)、windows(0) 这类必然 panic 的调用；
• RangeInclusive（a..=b 区间）的迭代在某些情况下被优化，已耗尽的区间再调用 start()、end() 或当作切片下标时行为可能变化，官方明确这类行为此前并未承诺稳定；
• riscv64-unknown-linux-musl 提升为带 host tools 的 Tier 2 目标；
• invalid_reference_casting lint 做了相应调整。

1.99.1 的补丁内容同样值得留意：库侧修复了 UEFI 与嵌入式目标上缺失 wcslen 符号的问题，编译器侧修复了 x86_64 上 FFI 返回 bool 值的错误编译，链接器侧补上了 macOS 上 libLLVM 的 rpath。如果你在做 FFI 或嵌入式，这一条就是必须升级的理由，而不是"追新"。

如果你还不熟悉所有权与借用这套核心概念，可以先跟一遍 Rust 语言基础，再回来看版本决策，会更容易判断哪些变化与你有关。

二、这次变化会影响谁

按角色分开看，结论差别不小。只在学习 Rust 的人，影响集中在"能不能编译通过"上，本轮稳定的宏与可变参数写法你未必立刻用得到，但新 lint 可能在你练手的代码里冒出提示；维护个人项目的人，影响集中在 CI 上，新增或调整过的 lint 会把原本静默的问题暴露成警告，配了 deny(warnings) 就会直接失败；团队协作或生产项目的人，影响在"工具链一致性"上，成员之间 rustc 版本不一致会出现"我这儿能编译、你那儿不行"的经典问题。

也需要说清一个适用边界：新特性不等于你现在就该用。本轮稳定的 C 可变参数与裸函数，主要服务 FFI、运行时、嵌入式这类场景；写业务代码的团队通常一整年都不会碰。把它们当作"以后遇到再查"的储备，比现在强行用上更合理。

从性能取舍上看，RangeInclusive 的迭代优化属于"不用改代码就能拿到"的收益，代价是已耗尽区间的行为不再保证；这条恰好是本轮唯一需要在升级后重新跑测试的隐性变更点。

三、新手该不该现在跟进：三种情况分开判断

这里补一条容易被忽略的边界：补丁版本和次版本号的处理方式不同。1.99.0 到 1.99.1 是补丁，按语义化版本约定只修问题，可以放心跟；而 1.98 到 1.99 是次版本升级，才需要按上面的表做判断。很多人把两者混为一谈，结果要么过度紧张，要么过度随意。

四、升级前的检查清单（含验证与回退）

下面按"看清现状 → 升级 → 验证 → 回退"排列。命令结果为预期结果（未在本机执行），请先在测试目录执行。

1. 看清当前装了什么

rustup show
rustc --version
cargo --version

预期输出会列出已安装的工具链、当前默认工具链和具体版本号。这一步确定你从哪个版本出发，也确认你是不是不小心把默认工具链设成了 nightly。

2. 升级并固定版本

rustup update stable

预期结果是拉取最新的稳定版并切换过去。常见失败分支是下载中断或提示组件缺失，根因多是网络与镜像源，重试或换镜像即可；若提示磁盘空间不足，先清理旧工具链：rustup toolchain uninstall 1.97.0。

升级完成后，建议在项目根目录写一个固定版本的配置文件，避免团队成员之间版本漂移：

# rust-toolchain.toml
[toolchain]
channel = "1.99.1"
components = ["rustfmt", "clippy"]

3. 验证：重点看 lint 与区间

fn main() {
    let data = [1, 2, 3, 4];
    // 1.99 起，unconditional_panic lint 会捕获这类必然 panic 的调用
    let _chunks = data.chunks(0);
    println!("{}", _chunks.len());
}

预期结果：cargo build 仍然成功，但会给出一条指出 chunks(0) 必然 panic 的警告；如果你的项目写了 #![deny(warnings)]，这条警告会直接变成编译失败。这就是升级后 CI 变红的典型原因，处理办法是把参数改成非零，或者给该函数单独加 #[allow(unconditional_panic)] 并注明理由。

4. 回退边界

Rust 的回退成本很低，这也是它比很多语言更适合"先试再定"的原因：

rustup toolchain install 1.98.0
rustup default 1.98.0

预期结果是回到上一个稳定版并重新编译通过。前提是你的项目没有依赖只在 1.99 才有的语法——一旦用了本轮新稳定的写法，就回不去了。所以顺序应该是：先升级工具链跑通，再考虑是否引入新语法，而不是反过来。

升级与回退涉及的命令较多，记不住时可以对照 Rust 教程 里的环境搭建与项目构建章节。

总结

Rust 1.99.0 于 2026-10-01 发布、1.99.1 于 2026-10-15 发布，这些是官方可核对的事实；而"要不要现在跟进"取决于你的项目类型与是否使用 FFI。学习环境直接装最新稳定版，个人项目先跑完整测试，团队与生产项目用 rust-toolchain.toml 锁版本再单分支验证，做 FFI 或嵌入式的团队则应尽快升到 1.99.1。本轮真正需要在升级后重点验证的，是新增 lint 与 RangeInclusive 的行为变化。

常见问题

Q：我刚开始学 Rust，装 1.99 会不会太新？

不会。稳定版之间向后兼容是 Rust 的基本承诺，新版本不会让教科书里的示例代码失效。真正要避开的是 nightly：语法和特性随时会变，排查成本远高于收益。

Q：升级后 CI 变红，一定是版本问题吗？

先怀疑 lint。本轮新增并调整了多个 lint，配了 deny(warnings) 的项目最容易把新警告当成错误。做法是本地跑一遍 cargo clippy，看新增警告指向哪一行，再决定改代码还是单独 allow。

Q：1.99.1 值得单独升吗？

如果你做 FFI、嵌入式或 macOS 上的链接相关工作，值得。1.99.1 修复了 x86_64 上 FFI bool 返回值的错误编译、UEFI 与嵌入式目标缺失 wcslen 的问题，以及 macOS 上 libLLVM 的 rpath。不碰这些场景的话，按常规节奏跟稳定版即可。

Q：能不能直接用 nightly 学新特性？

不建议。1.100 计划在 2026-11-12 转为稳定版，等两周就能在稳定版上用到，没必要承担 nightly 的不确定性和排查成本。

延伸学习

• 本轮涉及引用与借用，配合 Rust 生命周期标注 这篇笔记一起看更容易理解。
• 想知道 Rust 当前的生态热度与排名变化，可以参考 Rust 首进前十 这篇榜单笔记。
• 还在 Rust 与其他系统语言之间犹豫，可以先读 Go vs Rust对比 这篇笔记的取舍分析。