00:00:00
资料库 · Rust 与系统编程
第 ③ 卷，条目 41–60。来源为 blog.rust-lang.org（官方发布博客）与 Inside Rust（面向贡献者的开发过程博客）。
两个博客的定位区别值得先说清：官方博客写"发布了什么"，Inside Rust 写"正在做什么、以及为什么这么做"。想跟上语言走向，Inside Rust 的信息密度更高，但它默认读者已经熟悉编译器术语。
语言演进与借用检查
41. Enabling the next iteration of the borrow checker on nightly
来源：Rust 官方博客，2026 年 8 月。
读它解决什么：想知道下一代借用检查器（Polonius）的进展，以及它能解决哪些现在被拒的合法代码。
要点：
- 新一代借用检查器在 nightly 上启用，标题称之为 "next iteration"
- 时间点 2026 年 8 月，处于 alpha 阶段
我的补充：Polonius 这条线做的是让借用检查更精确，而不是更宽松——目标是接受那些逻辑上安全、但现有 NLL（non-lexical lifetimes）实现推不出来的代码。最经典的被拒模式是条件返回引用：
rust
fn get_or_insert(map: &mut HashMap<K, V>, k: K) -> &mut V {
if let Some(v) = map.get_mut(&k) { return v; }
map.insert(k, V::default()); // 现在会报 borrow 冲突
map.get_mut(&k).unwrap()
}这段人眼看着没问题（两个借用不重叠），但当前的检查器认为 get_mut 的借用活到函数结束。所以大家只能用 entry API 绕过。如果你曾经因为这类误报而怀疑自己没理解所有权——很多时候你理解得没错，是检查器保守。
42. Supply chain attack on arrayref
来源：Rust 官方博客，2026 年 8 月 20 日。
读它解决什么：一次真实发生在 crates.io 生态上的供应链攻击，事件通告与影响范围。
要点：
arrayrefcrate 遭供应链攻击，官方发出通告- 发布日期 2026 年 8 月 20 日，是本资料库收录截止当天的事件
我的补充：arrayref 是那种你不知道自己在用的包——体积极小、被大量密码学与解析类 crate 间接依赖。这类包正是供应链攻击最理想的目标：维护者少（往往就一个人）、审计关注度低、传递依赖面极广。要做的事情很具体：cargo tree -i arrayref 看自己有没有被牵连，装 cargo-audit 或 cargo-deny 进 CI，并且把 Cargo.lock 提交进版本库（库项目也要提，只是不会影响下游）。另外这条和 第一卷第 15 条 讲的 attestation 是同一个问题的两个生态：仅靠哈希无法防住"合法维护者账号被盗后发布的新版本"。
43. Rust Function Overloading - Call for Experimentation
来源：Inside Rust，2026 年 8 月。
读它解决什么：Rust 要不要支持函数重载，这是征集实验反馈的公告。
要点：
- 函数重载的实验性提案，公开征集试用与反馈
- "Call for Experimentation" 表示尚在探索阶段，未定论
我的补充：Rust 一直没有传统的函数重载，社区惯用做法是 trait + 泛型（impl Into<String> 这种）。重载的诱惑在于 API 更好用，风险在于它会让类型推导变得脆弱——一旦一个名字有多个候选签名，推导失败时的报错信息通常极难读（C++ 的重载决议错误就是反面教材）。这类 "Call for Experimentation" 是普通用户能真正影响语言走向的少数窗口，值得去试并反馈，因为最终决定往往取决于实验期收到的真实用例。
44. Call for testing: Restricting trait implementability and field mutability
来源：Inside Rust，2026 年 8 月。
读它解决什么：想在自己的库里限制 trait 被外部实现、或限制字段可变性，这是相关特性的测试征集。
要点：
- 两个特性同时征集测试：限制 trait 的可实现性、限制字段的可变性
- 面向库作者的 API 设计能力
我的补充：这两个都是给库作者用来控制向后兼容面的工具。现在想禁止外部实现某个 trait，只能靠 sealed trait 那套 hack（在 trait 里塞一个私有的父 trait），能用但意图完全不明显，报错信息也莫名其妙。字段可变性限制的价值类似：你想让结构体字段公开可读、但只能通过方法修改，现在只能全私有加一堆 getter。这两个特性落地后，"公开 API 的哪部分是承诺、哪部分是实现细节"能表达得清楚很多。
45. The many journeys of learning Rust
来源：Rust 官方博客，2026 年 6 月，Rust vision doc 的一部分。
读它解决什么：想了解不同背景的人学 Rust 时的真实路径与卡点。
要点：
- 属于 Rust 愿景文档（vision doc）的内容，主题是学习路径的多样性
- 强调"多条路径"而非单一学习曲线
我的补充：这份材料对带团队学 Rust 的人比对个人学习者更有用。它隐含的一个判断我很同意：从 C++ 来的人和从 Python/TypeScript 来的人，卡点完全不同。C++ 背景的人卡在借用检查的严格（"我知道这里是安全的"），脚本语言背景的人卡在更基础的地方（栈和堆、值和引用的区别）。用同一套教程带两拨人，效果一定很差。我给脚本语言背景同事的建议是：先别碰 Rc<RefCell<T>> 和生命周期标注，用 clone() 硬过第一个月，把程序跑通比写出零拷贝的代码重要得多。
工具链与生态
46. crates.io: development update
来源：Rust 官方博客，2026 年 7 月。
读它解决什么：想了解 crates.io 这个包仓库自身的开发进展。
要点：
- crates.io 的开发进度更新，2026 年 7 月
- 覆盖仓库平台侧的变化而非语言变化
我的补充：包仓库的改动容易被忽略，但它直接影响 CI。历史上 crates.io 的索引协议从 git 仓库改成 sparse HTTP（sparse+https://），效果是把冷启动 CI 里那次动辄十几秒的全量索引克隆，变成按需拉取——这是近年对 Rust CI 时间影响最大的单一改动。类似的平台侧变化值得跟，因为它们通常不需要你改代码，只需要更新工具链就能拿到收益。
47. Experiment in reducing target directory size on nightly
来源：Inside Rust，2026 年 8 月。
读它解决什么：target/ 目录动辄几十 G，这是官方在缩小它的实验。
要点：
- nightly 上的实验，目标是减小
target目录体积 - 属于工具链侧改进
我的补充：target/ 膨胀是 Rust 开发体验里最实在的抱怨之一，一个中等项目占掉 10–30 GB 很常见，笔记本 SSD 很快就见底。原因是每个依赖的每种配置（debug/release、每个 feature 组合）都留完整产物，加上调试信息体积巨大。等官方方案落地之前，两个立刻能用的手段：cargo clean -p <crate> 只清单个包而不是全清；在 Cargo.toml 里对 dev profile 设 debug = 1（行号级调试信息，不含完整类型信息），体积能砍掉一大半而 backtrace 仍然可用。另外用 CARGO_TARGET_DIR 指到统一目录，多项目可以共享编译产物。
48. 1.98.0 pre-release testing
来源：Inside Rust，2026 年 8 月。
读它解决什么：1.98 的 beta 测试征集，想提前发现自己的代码在新版本上的问题。
要点：
- Rust 1.98.0 的预发布测试公告
- 与 1.97.1 之后的六周发布周期对应
我的补充：Rust 是六周固定发布，节奏比 Go 和 Python 都快得多，所以"要不要升"这个问题基本不用讨论——跟上就好，破坏性变更极少。真正值得做的是在 CI 里加一条 beta 通道（允许失败）。这样每六周你都提前知道新版本会不会给你带来新的 lint 警告或 deny 级别的报错。Rust 的做法是发现回归就在正式发布前撤掉改动，所以你在 beta 期间报的问题真的会被处理，这个反馈回路是有效的。
49. Leadership Council September 2026 Representative Selections
来源：Inside Rust，2026 年 8 月。
读它解决什么：想了解 Rust 项目的治理结构与代表选任机制。
要点：
- Rust 领导层委员会 2026 年 9 月的代表选任
- 属于治理流程公告
我的补充：治理公告和写代码没关系，但对技术选型有关系。做长期技术决策时，"这个项目由谁决定、决策过程是否公开、有没有单一公司能单方面改方向"是实打实的风险项。Rust 从 2021 年核心团队集体辞职的危机之后，重建了这套有明确章程的委员会结构，把权力从模糊的"核心团队"改成有代表来源和任期的机制。对比一下那些由单一公司控制、随时可能改许可证的项目，这种流程上的冗余不是官僚，是稳定性的来源。
50. June 2026 Project Director Update
来源：Inside Rust，2026 年 8 月。
读它解决什么：Rust 基金会 project director 的工作更新。
要点：
- Project director 的定期更新，覆盖 2026 年 6 月
- 反映基金会与项目之间的协作情况
我的补充：这类更新里最值得关注的一般是基础设施经费。Rust 的 CI 消耗巨大（每次合并要在多平台上跑完整测试和多阶段引导构建），这些成本由基金会和赞助的云资源承担。当你看到构建时间上限、CI 资源分配之类的讨论时，背后通常是钱的问题。这也解释了为什么 target 目录体积、编译时间这类议题在 Rust 社区被反复提起——它对项目自身的成本也是真金白银。
版本发布线（1.85 → 1.97）
这一段按时间倒序收录关键的版本公告。Rust 六周一发，全收没有意义，我挑的是带 edition、带整数版本、或者本身是安全修复的那几个。
51. Announcing Rust 1.97.1
来源：Rust 官方博客，2026 年 7 月 16 日。
读它解决什么：1.97.1 修了什么，要不要跟这个 point release。
要点：
- 1.97.1 是 1.97.0 发布一周后的补丁版本
- Rust 的
.1版本只在发现重要回归或安全问题时才发
我的补充：Rust 的发布节奏里 .1 版本是个信号——它不是常规计划的一部分。看到 x.y.1 紧跟 x.y.0 出现，说明 x.y.0 里有值得紧急修的东西。所以我的策略是：.0 版本发布后不急着在生产 CI 上切，等一周看有没有 .1。这个等待成本几乎为零，收益是避开已知回归。
52. Announcing Rust 1.97.0
来源：Rust 官方博客，2026 年 7 月 9 日。
读它解决什么：1.97 的稳定化特性清单。
要点：
- Rust 1.97.0 发布公告
- 一周后跟了 1.97.1（见上条）
我的补充：读 Rust 发布公告的高效方式是跳过正文直接看底部的 "Stabilized APIs" 列表。正文通常挑一两个特性详细讲，但对日常写代码影响最大的往往是那些一句话带过的标准库 API 稳定化——某个你一直得手写的辅助函数，可能这一版进标准库了。我的习惯是每次发版扫一遍这个列表，然后去搜自己代码里有没有可以删掉的手写实现。
53. Announcing Rust 1.96.1
来源：Rust 官方博客，2026 年 6 月 30 日。
读它解决什么：1.96 的补丁版本。
要点：
- 1.96.1，发布于 1.96.0 之后约一个月
- 又一个非计划的 point release
我的补充：注意 1.96 和 1.97 都出了 .1，连续两个版本都有紧急补丁。这种情况下我会把"等一周"的策略延长——如果你的项目对工具链稳定性敏感（比如给客户交付编译产物），把 CI 固定在 rust-toolchain.toml 里指定的具体版本，而不是跟 stable 浮动。rust-toolchain.toml 提交进仓库，团队里每个人和 CI 用的编译器就必然一致，这能消除一整类"我这儿能编过"的问题。
54. Announcing Rust 1.96.0
来源：Rust 官方博客，2026 年 5 月 28 日。
读它解决什么：1.96 的稳定化内容。
要点：
- Rust 1.96.0 发布公告
我的补充：跨多版本升级时，别一个个读公告——用 cargo clippy --fix 加上新工具链跑一遍，让工具告诉你哪里该改。Rust 的 lint 在版本间会新增，clippy 的自动修复覆盖率相当高。人工读 changelog 适合了解方向，机器扫代码适合找具体问题，两件事分开做。
55. Announcing Rust 1.95.0
来源：Rust 官方博客，2026 年 4 月 16 日。
读它解决什么：1.95 的稳定化内容。
要点：
- Rust 1.95.0 发布公告
我的补充：从 1.95 往前推，Rust 在 2026 年上半年保持了大约六周一版的节奏（1.94 在 3 月，1.95 在 4 月，1.96 在 5 月）。这个节奏本身是有信息量的：它意味着任何单个版本都不会有大改动。所以"我该升到哪一版"这个问题在 Rust 里几乎不存在，升到最新就是最优选择，风险由六周的小步幅摊薄了。
56. Announcing Rust 1.94.1
来源：Rust 官方博客，2026 年 3 月 26 日。
读它解决什么：1.94 的补丁版本。
要点：
- 1.94.1，发布于 1.94.0 之后约三周
- URL 形式是
1.94.1-release，与其他版本的Rust-x.y.z略有不同
我的补充：顺带一个实用细节：Rust 官方博客的 URL 命名不完全一致（这一条是 1.94.1-release，其他多数是 Rust-1.94.0）。如果你写脚本按规律拼版本公告的 URL，会在这类特例上失败。要稳的话解析 feed.xml 或者 /releases/ 索引页，别猜 URL——这个教训对所有"按规律构造 URL"的抓取都适用。
57. Announcing Rust 1.94.0
来源：Rust 官方博客，2026 年 3 月 5 日。
读它解决什么：1.94 的稳定化内容。
要点：
- Rust 1.94.0 发布公告
我的补充：如果你要在团队里推动"定期升级工具链"这件事，Rust 是最容易立规矩的语言：把"每两个版本升一次"写进流程，成本极低。难的反而是MSRV（minimum supported Rust version）——如果你在发布库，用了新版本的特性就等于抬高了下游的门槛。库项目应该在 Cargo.toml 里显式声明 rust-version，让 cargo 在版本不够时给出清楚的报错，而不是让下游看到一堆看不懂的语法错误。
58. Announcing Rust 1.93.0
来源：Rust 官方博客，2026 年 1 月 22 日。
读它解决什么：1.93 的稳定化内容，2026 年的第一个版本。
要点：
- Rust 1.93.0 发布公告，2026 年 1 月
我的补充：年初这一版适合作为"年度升级审计"的锚点：把 Cargo.toml 里的 edition、rust-version、以及依赖的大版本一起过一遍。我的经验是这种批量维护一年做一到两次最合适——比每次发版都动省事，又不会攒到依赖跨了三个大版本、升级变成重写。
59. Announcing Rust 1.87.0 and ten years of Rust!
来源：Rust 官方博客，2025 年 5 月 15 日。
读它解决什么：Rust 1.0 十周年的纪念版本公告。
要点：
- 1.87.0 与 Rust 1.0 发布十周年重合（2015 年 5 月 15 日 → 2025 年 5 月 15 日）
- 兼具版本公告与回顾性质
我的补充：十年这个时间点值得单独记一笔，因为它是"Rust 的稳定性承诺经受住了检验"的证据。2015 年写的 Rust 代码，用 2025 年的编译器基本还能编过——这在系统语言里不容易做到。edition 机制（2015/2018/2021/2024）是关键：破坏性变更被隔离在 edition 里，且不同 edition 的 crate 可以互相依赖，所以生态不会分裂。和 第二卷第 39 条 Go 的 go.mod 语言版本声明是同一个思路，两边都在避免 Python 2→3 那种断代。
60. Announcing Rust 1.85.0 and Rust 2024
来源：Rust 官方博客，2025 年 2 月 20 日。
读它解决什么：Rust 2024 edition 正式发布，想知道要不要迁移、怎么迁移。
要点：
- 1.85.0 同时带来 Rust 2024 edition
- edition 是 Rust 唯一允许破坏性变更的机制
我的补充：本卷里最该完整读一遍的就是这条。edition 迁移的实际操作比听起来简单：cargo fix --edition 能自动处理绝大部分，然后改 Cargo.toml 里的 edition = "2024"。关键认知是 edition 是 per-crate 的——你的 crate 升到 2024，依赖仍然停在 2015 也完全正常，编译器分别按各自的 edition 处理。所以不存在"要等生态都迁完再迁"的问题，这和 Python 2→3 的处境根本不同，那次是运行时层面的分裂，没有隔离机制。2024 edition 里影响面较大的是 unsafe_op_in_unsafe_fn 变成默认警告（unsafe fn 内部不再自动获得 unsafe block 的豁免），这个改动方向是对的：它逼你标出函数里具体哪一行才是危险的，而不是把整个函数当黑箱。
本卷小结
三个带走的结论：
- 借用检查器报错不一定是你错了。 条件返回引用这类模式是当前 NLL 实现的已知保守之处，Polonius 正在修。遇到"我确信这是安全的"的报错，先搜一下是不是已知误报，再考虑重写。
Cargo.lock要提交，cargo-audit要进 CI。 第 42 条那次arrayref供应链攻击命中的正是"你不知道自己在用"的微型传递依赖，靠人工审计是不可能发现的。- edition 是 per-crate 的。 迁移到新 edition 不需要等生态，
cargo fix --edition加改一行配置就能完成。这个隔离机制是 Rust 敢做破坏性变更还不分裂生态的根本原因。
上一卷： ← ② Go 语言与并发 · 下一卷： ④ 打包、依赖与容器化 →