Rust 项目管理动态 — 2026 年 3 月

本文基于 Rust 官方 Inside Rust 博客于 2026 年 4 月 9 日发布的《Program management update --- March 2026》，作者为 Tomas Sedovic 与 Nurzhan Saken，代表 Program 团队发布。

内容结构概览

团队会议安排的新变化
项目管理看板上线
项目目标（Project Goals）最新进展
FLS 发布说明流程改进
crates.io 与 Rust 版本镜像
Rust 基金会维护者基金（RFMF）RFC
Outreachy 实习项目
Rust for Linux
Rust for CPython
- Drop with context
- Sanitizer 兼容性
- 未来会议安排
近期值得关注的资讯
数据统计

一、团队会议安排的新变化

随着 Nurzhan 完成入职适应，他已经能够独立出席各团队会议，不再需要与 Tomas 同时参加。这让两人得以平均分担会议工作量，同时维持相同的 PM 覆盖水平。两人可以相互顶替缺席，而各自的会议压力也降低了约一半。

这是一个实质性的改善。参与决策现场、协助各方、将讨论记录留存固然有其价值，但这也是高度消耗精力的工作------尤其是在连续安排了六七个小时背靠背会议的那些天。

目前的会议分工仍在摸索调整之中，但两人有意识地选择了不做功能分化：双方都参与每个团队的讨论，与各方人员建立彼此了解的关系。这样做有利于知识和上下文的共享，也方便在其中一人无法出席时由另一人顶上。当然，两人也保持着持续的沟通，互相阅读对方参加的会议记录，并确保跨会议需要跟进或移交的事项得到妥善处理。

这种安排为两人腾出了更多精力去推进其他工作。

会议层面还发生了两项变化：

其一，Josh Triplett 提议暂时暂停 Style 团队的会议。过去数月（以及更早之前的零散时期），实际参会的 Style 团队成员只有两人。团队目前亟需补充成员（rustfmt 亦然），理想情况下还需要一位 rustfmt 联络人参与会议。在寻找解决方案的同时，紧急事项暂时通过异步方式处理。

其二，两个 Libs-API 会议合并为一个。此前，团队分别有一个会议用于处理被提名的 issue 和 PR，另一个专门审议开放中的 API 变更提案（ACP），两者均在周二举行，中间间隔一小时。然而两者之间的边界并不明确------如果第一个会议把提名积压清空了，往往会自然地延伸到 ACP 的讨论。而与会者本来就希望直接继续。两次会议现已合并，大家既能一气呵成地开完，又能整体提前一小时结束------如果讨论特别耗神，节省的时间还不止于此。

二、项目管理看板上线

Rust 项目管理看板已经填充了内容，现在可以在上面看到团队正在推进的工作。这有助于更好地跟踪和协调各项工作，同时也提升了透明度。看板地址：https://github.com/orgs/rust-lang/projects/69/views/2

三、项目目标（Project Goals）最新进展

2026 项目目标 RFC（https://github.com/rust-lang/rfcs/pull/3935）现已正式开放！这是 Goals 团队过去数月工作的集中呈现。

欢迎前往查看，如有疑问，可以访问 Zulip 上的 project-goals/2026-workshop 频道。如果你是某个团队的负责人，请务必审阅 RFC，并提出意见或在你负责的条目上打勾确认。

与此同时，2025 H2 目标周期也即将收尾。团队正在准备最后一次进展更新（计划在 2026 RFC 合并后发布），之后将全力投入 2026 目标周期的推进。

2025 年的不少目标将延续至 2026 年周期，这部分不会有太大变化，原有的跟踪 issue、Zulip 频道等基础设施都将继续沿用。新增的目标将创建专属跟踪 issue，所有进展更新都应发布于此，并自动同步到对应的 Zulip 频道，以便展开讨论。

此外，团队每月还会发送两次提醒，督促目标负责人发布更新（如果近期已有更新，则不会重复发送提醒）。

四、FLS 发布说明流程改进

FLS（Ferrocene Language Specification）是 Rust 面向汽车等安全关键领域的语言规范文档，最初由 Ferrous Systems 开发，后捐赠给 Rust 项目，现由 FLS 团队维护。

作为"稳定化 FLS 发布流程"项目目标的一部分，FLS 团队计划在每次 Rust 版本发布后六周内同步发布对应的 FLS 新版本。

此前，他们的工作方式是在 Rust 版本发布后，逐条翻查发布说明，找出需要反映到文档中的语言层面变更------这本质上是一种事后追赶式的流程。他们希望能提前介入，但这需要在发布说明全部整理完毕之前，就能拿到某次发布所包含的 issue 列表。

为此，Pete LeVasseur 联系了 Release 团队，并达成协议，尝试参与发布 issue 的早期分类流程。这样一来，FLS 团队既能更深入地理解发布流程、提供帮助，又能提前获取所需的 issue 列表，实现双赢。

这也是一个很好的提醒：Rust 的发布流程是完全公开的（https://forge.rust-lang.org/release/release-notes.html），欢迎更多贡献者参与，这也可以作为深度参与 Rust 社区贡献的一个较为友好的入口。

五、crates.io 与 Rust 版本镜像

三月初，团队正式开放了"实现可验证镜像原型"（https://rust-lang.github.io/rust-project-goals/2026/mirroring.html）项目目标。这是此前签名探索工作的延续，但聚焦范围更窄。目标是为 Rust crate 和发布版本建立镜像服务，以解决 GitHub Actions 等高流量环境中的访问问题。

该原型将验证所提议的技术方案（例如使用 The Update Framework，即 TUF，来校验镜像更新）以及密钥轮换机制，同时提供能够实际减少带宽用量和成本的功能（通过让 GitHub Actions 访问托管在 Azure 上的镜像来实现）。

相关功能将在不稳定特性标志（unstable feature flag）背后实现，但一旦验证可行，可以以此为基础构建更通用的镜像支持能力。

在该目标的跟踪 issue 创建之前，进展更新将发布在 Zulip 的 tbd-signing 频道中。

六、Rust 基金会维护者基金（RFMF）RFC

早在 2025 年 12 月，团队就提及了维护者基金的计划以及 RFMF 设计委员会的成立。设计委员会随后采访了几个拥有类似项目的开源组织（包括 Python Software Foundation、Scala Center、Django 和 Zig Software Foundation），并在此基础上提出了一份 RFC（https://github.com/rust-lang/rfcs/pull/3931）。

该 RFC 提出设立"常驻维护者（Maintainer in Residence）"角色：

常驻维护者项目致力于雇用长期维护者并为其全职维护工作提供资金支持。常驻维护者的时间在两类优先事项之间分配：一类是他们所支持的团队给出的指导性优先事项，另一类是他们在项目内自主选择的优先事项。

这些维护者预期是在社区中有良好声誉的项目成员，能够长期致力于保持项目的健康运转与持续演进。

RFC 同时提议组建一个资助团队，与 Leadership Council 共同遴选候选人，并确保整个项目的顺利推进。

这一计划与另一个资助项目提案（https://github.com/rust-lang/rfcs/pull/3919）形成互补------后者面向已经在为项目做出有价值贡献的人，提供为期十二个月的资金支持。他们不是被雇用或签约，而是以此认可他们出色的工作，并帮助他们更好地持续下去。

七、Outreachy 实习项目

Rust 项目正式参与 Outreachy（https://www.outreachy.org/）！这是一个面向科技行业中代表性不足群体的带薪开源实习项目。

Leadership Council 为 2026 年 5 月至 8 月的实习周期拨款，提供三个实习名额。目前共有五个项目可供申请：

向现有 C/C++ 构建系统中添加 Rust 支持
从 Rust 调用重载的 C++ 函数
大规模对 Rust 编译器进行代码覆盖率测量
对 a-mir-formality 类型系统实现进行模糊测试
改进 GitHub Actions 的安全性

目前处于贡献期阶段，申请者需要向项目提交贡献，这些贡献将作为选拔实习生的重要依据。

Tomas 对此表达了个人的由衷喜悦------他对 Outreachy 所做的事情和所代表的价值观深表认同，也与多位曾参与该项目的人共事过，对他们印象极佳。

特别感谢 Jack Huey 负责组织这一切！同时感谢 Niko、Rémy、tiif、teor、Joel Marcey 和 Ethan Smith 报名担任导师和联合导师。

八、Rust for Linux

负责常量泛型（const generics）目标的 Boxy 希望了解哪些方向对 Rust for Linux 团队最为重要。常量泛型这把"大伞"下涵盖了大量功能点，明确优先级至关重要。

Rust for Linux 团队重点提出了以下三个方向：

1. 对常量泛型类型执行算术运算

内核中存在一个类型 Bounded，它同时持有一个值和一个最大位宽，两者均为常量值。团队希望能对这类类型进行算术运算（从位移运算开始），从而在编译期保证结果不超出指定的位宽范围。

2. 参数位置常量泛型（Argument-position const generics）

目前，常量泛型类型必须写在尖括号内的类型约束区域，例如必须写成 Bounded::<u8, 4>::new::<7>()，而不是更自然的 Bounded::<u8, 4>::new(7)。当涉及编译期计算而非简单数值常量时，情况会更复杂------还需要用花括号包裹：{ ... }。

3. 支持数值以外的类型作为泛型参数

指针类型将对 asm_const_ptr 很有用；字符串字面量也很实用，哪怕只是作为透传参数，不做任何处理或操作。如果从支持透传字符串出发，进而能透传任意类型，将有助于团队用枚举（enum）替换掉目前大量使用的类型状态（typestate）模式。

其他进展

Gary 为内核添加了一套通过宏实现指针投影的基础设施，dma_read! / dma_write! 宏已经切换至这套新机制。值得注意的是，这完全通过宏实现，并未使用任何字段投影（Field projections）语言特性。未来，字段投影的语法和 trait 支持将使这一工作更加符合人体工学，并可以借助借用检查器接受更多合法代码。

在字段投影方面，Lang 团队召开了一次设计会议，讨论了 Benno Lossin、Nadrieril 和 Tyler Mandry 联合提出的最新方案------通过虚拟 Place（Virtual Places）实现字段投影。相关提案和会议记录可在字段投影项目目标页面查阅（https://rust-lang.github.io/rust-project-goals/2026/field-projections.html）。

此外，作为此前 rustfmt use 语句讨论的后续，Tomas 提交了一个 issue（https://github.com/rust-lang/rustfmt/issues/6829），要求支持将 import 语句保持在单独行上的格式化方式，以满足 Rust for Linux 的需求，从而避免使用尾部 // 注释作为变通手段。

九、Rust for CPython

三月份，团队与 CPython 方面进行了一次会议。

Drop with context（带上下文的析构）

Python 对象是引用计数指针。在任何给定时刻，这些对象要么附着在 Python 解释器上，要么处于分离状态。当处于附着状态时，其引用计数可以增减，但若要进行任何原生调用，则必须先解除与解释器的关联。这类指针无法实现 Clone 或 Drop trait，因为 trait 的实现不知道对象当时是否附着于解释器状态。

如何在 Rust 中对此进行建模，同时保证安全性与易用性，是一个尚未解决的开放问题。

David Hewitt 就"带上下文的 Drop（Drop with context）"特性展开了咨询------该特性要求在调用 drop 函数时隐式传入一个关联上下文（例如指向 Python 解释器状态的指针）。

这是 Rust 项目一直在思考的方向（可参见 Tyler Mandry 2021 年的博客文章、Nadrieril 近期发布的《What If Traits Carried Values》，以及相关的 2026 年字典传递风格实验目标提案）。David、Josh Triplett 和 Jack Huey 计划在 Zulip 上以及 2026 年 All Hands 期间继续深入讨论这一议题。

Sanitizer 兼容性

CPython 在 CI 中运行多种 sanitizer（包括 AddressSanitizer/ASan、MemorySanitizer/MemSan、UndefinedBehaviorSanitizer/UBSan 和 ThreadSanitizer/TSan），以对 C 代码进行额外的合规性检查，这对 Python 的内存安全至关重要。

Emma Smith 希望确认 LLVM 和 GCC 的 sanitizer 是否可以混用------答案是否定的。引入 Rust 后，Python 解释器中的 C 代码部分将不得不使用 Clang 进行编译，并使用 Clang 自带的 sanitizer，同时需要确保这些 sanitizer 与原有的覆盖范围一致。

团队还询问了 LLVM 各版本间的兼容性问题，因为 Rust 使用了自己维护的 LLVM fork。结论是：LLVM 主版本之间互不兼容，但 Rust 的 fork 与对应的上游版本应当是兼容的，Rust 会向自己的 fork 中移植上游的 bug 修复，也支持使用原版 LLVM 进行构建。

此外，由 Rust for Linux 推动的稳定化 MemorySanitizer 和 ThreadSanitizer（https://rust-lang.github.io/rust-project-goals/2026/stabilization-of-sanitizer-support.html）工作也在持续推进中。

未来会议安排

本月初之后，双方暂时没有新议题，会议因此暂时搁置。有新话题出现时将重新开始，但目前阶段双方各自都有大量的实际工作要推进。Rust 和 CPython 两侧的团队计划在 2026 年 All Hands 期间举行一次联合会议。

与此同时，Emma Smith 从 CPython 视角发布了一篇进展更新（https://blog.python.org/2026/04/rust-for-cpython-2026-04/）。团队已完成构建系统的相关工作，并通过了 CPython 的 CI 验证。接下来数月，他们将规划内部 Rust API 的设计，之后撰写 PEP（Python Enhancement Proposal，类似于 Rust 的 RFC），目标版本为 Python 3.16。

十、近期值得关注的资讯

Rust 基金会文章

Canonical 以黄金会员身份加入 Rust 基金会（https://rustfoundation.org/media/canonical-joins-the-rust-foundation-as-a-gold-member/）
Rust 创新实验室的下一步计划（https://rustfoundation.org/media/whats-next-for-the-rust-innovation-lab/）

Rust 项目动态

Rust 1.94.0 正式发布（https://blog.rust-lang.org/2026/03/05/Rust-1.94.0/）以及 1.94.1（https://blog.rust-lang.org/2026/03/26/1.94.1-release/）
Cargo 安全公告（https://blog.rust-lang.org/2026/03/21/cve-2026-33056/）
WebAssembly 目标与未定义符号处理变更（https://blog.rust-lang.org/2026/04/04/changes-to-webassembly-targets-and-handling-undefined-symbols/）：**破坏性变更**预警，影响 WebAssembly 构建
docs.rs：默认构建目标减少（https://blog.rust-lang.org/2026/04/04/docsrs-only-default-targets/）：**破坏性变更**预警，将于 2026 年 5 月 1 日生效
我们听到了哪些关于 Rust 挑战的声音（https://blog.rust-lang.org/2026/03/20/rust-challenges/）
rustup 1.29.0 正式发布（https://blog.rust-lang.org/2026/03/12/Rustup-1.29.0/）
2025 年 Rust 状态调查结果（https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/）
测试征集：构建目录布局 v2（https://blog.rust-lang.org/2026/03/13/call-for-testing-build-dir-layout-v2/）：自 Cargo 1.91 起，中间构建产物（build-dir）和最终产物（target-dir）可以分离存放。Cargo 正在调整 build-dir 的目录结构（target 目录布局不变），征集用户测试以发现诸如构建脚本依赖目录结构来推断 target_dir 或可执行文件路径等问题，欢迎参与测试并反馈
2026 年 1 月 & 2 月项目董事更新（https://blog.rust-lang.org/inside-rust/2026/03/25/project-director-update/）
Leadership Council 更新 --- 2026 年 3 月（https://blog.rust-lang.org/inside-rust/2026/04/06/leadership-council-update/）：Rémy Rakic 担任编译器团队代表，Josh Triplett 担任 Libs 团队代表

十一、数据统计

以下数据反映了 Program 团队 3 月份的工作量：

会议记录总字数（2025 年 6 月 --- 2026 年 3 月）：470,500 字
参加会议总场次（3 月）：35 场
3 月份会议记录字数：73,800 字
各团队单次会议平均字数 ：
- Cargo：1,900 字
- Lang triage：3,300 字
- Libs-API：4,300 字
- Leadership Council：2,400 字

原文地址：https://blog.rust-lang.org/inside-rust/2026/04/09/program-management-update-2026-03/

作者：Tomas Sedovic、Nurzhan Saken，代表 Program 团队