Rust 项目进展月报：2026 年 1 月

本文是对 Rust 官方 Inside Rust 博客《Program management update --- January 2026》的完整中文解读。作者为 Tomas Sedovic，代表 Goals 团队发布于 2026 年 2 月 11 日。

内容结构概览

项目目标（Project Goals）：2026 全年计划正式推进
- 当前进度与阶段安排
- 2026 年的重要机制变化：路线图与应用领域
招募第二位项目经理：Nurzhan Saken 正式加入
Rust for Linux：新进展与专属路线图
CPython 合作：探索将 Rust 引入 Python 解释器
cargo-script：距离稳定版仅一步之遥
- 基础用法与完整代码示例
- front matter 稳定化的曲折历程
crates.io 镜像与验证：建立透明的协作机制
值得关注：近期 Rust 相关文章汇总
运营数据统计

一、项目目标：2026 全年计划正式推进

当前进度与阶段安排

2026 年的项目目标计划已全面启动。在提案征集公告发出之后，贡献者们陆续为新目标提交了 pull request。与此同时，2025 年的许多目标也计划延续至 2026 年继续推进。

截至目前，已有约 60 个目标被提出，后续还会有若干补充。目前整个计划正进入第二阶段。

各阶段安排如下：

二月（进行中） ：公开征集对各目标的反馈------尤其来自被要求投入资源的团队。各团队成员可查阅按团队划分的目标列表，找到自己所在的团队，确认涉及本团队的所有目标，评估这些目标的合理性、团队当前的承载能力，以及是否有合适的 Champion 可以认领。

三月：正式开放 2026 目标 RFC，所有相关团队的负责人将对目标总体情况进行审查，确认 Champion 安排和团队承载能力后正式签字。

四月至十二月：进入实施阶段。

2026 年的重要机制变化

除了将目标计划延展为全年周期以外，本轮还引入了若干重要的机制调整。

旗舰主题（Flagship Themes）让位于路线图（Roadmaps）

许多大型目标的完成周期并不能对应一个六个月甚至一年的窗口期。目标的设计要求在单年内可完成，但例如完整实现 async 特性与人体工学改进这样的工作，预计将跨越多年才能完成。路线图正是为此而设------它为跨年度的长期技术方向提供持续的导航框架。

一个目标可以同时归属于多个路线图。

应用领域（Application Areas）

在路线图之上，还引入了"应用领域"层级，例如"跨语言互操作"（Cross-language interop）或"安全关键与受监管场景"（Safety-critical & regulated）------这些是往往与特定行业高度对齐的大型倡议方向。

引入应用领域的一个重要期望是：它们能够帮助吸引来自行业的定向资金。例如，汽车行业的公司可能对资助"安全关键"领域有强烈兴趣，因为其使用的代码和库需要经历成本高昂的合规认证；而拥有大量 C++ 代码库的公司则会更关注"跨语言互操作"方向。

高亮目标（Highlights）

此外，还专门整理了一份值得特别关注的目标清单------这些是团队认为社区会感兴趣、并预计在今年内完成稳定化的目标。需要注意的是，该清单在最终审定所有目标之前仍可能有所调整。

完成上述全部工作是 Niko Matsakis、Rémy（lqd）和作者 Tomas Sedovic 共同投入大量精力的成果。在此感谢所有提交提案、参与讨论的贡献者。

二、招募第二位项目经理

最初，领导委员会（Leadership Council）计划招募两位项目经理，以保证工作的延续性、互备能力，以及足够的容量来承接项目各方面的需求。然而由于 2025 年预算尚不明朗，委员会当时仅招募了一位（即本文作者 Tomas Sedovic）。

在 2026 年的基金会资金计划确认之后，领导委员会专项拨款用于招募第二位项目经理，这使得团队得以联系到 Nurzhan Saken------一位早在 2025 年 6 月就已被纳入招募候选的人选。

Tomas 与 Nurzhan 进行了深入交流，也由此理解了当初 TC 和 Joel Marcey 力主招募他的原因。

Nurzhan 已于 2026 年 2 月初正式加入项目团队。

三、Rust for Linux：新进展与专属路线图

Rust for Linux 的相关工作在 1 月持续推进，定期会议照常进行。完整的进展可在 Rust for Linux 项目目标追踪 issue 中查阅。

主要亮点：

新的 Wiki 上线 ：现已有一个专属 wiki，内容涵盖字段投影（Field Projection）、原地初始化（In-place initialization），以及其他规划中的语言特性，为相关开发者提供系统性的文档参考。

Supertrait auto impl 新目标提案 ：Ding Xiang Fei 为 2026 年提交了 Supertrait auto impl 项目目标提案。

汇编 RFC 实现进展 ：Gary Guo 提交了一个实现 Pass pointers to const in assembly RFC#3848 的 pull request。

Rust for Linux 专属路线图 ：Tomas Sedovic 提交了一个 pull request，提议为 Rust for Linux 建立专属路线图。该路线图将现有的独立目标（字段投影、原地初始化和 Supertrait auto impl）纳入统一框架，并将原始语言特性需求拆分为独立的细粒度目标。

这样做的好处是：所有 Rust for Linux 相关工作都可以在同一个路线图条目下进行追踪，同时每个子目标更加聚焦，也更易于审查和执行。

四、CPython 合作：探索将 Rust 引入 Python 解释器

Rust 项目团队正与对将 Rust 引入 CPython（用 C 编写的权威 Python 解释器）感兴趣的 Python 社区人士保持每周例会。参与方涵盖来自 Compiler、Cargo、Libs-API 和 Language 团队的代表，并在需要时邀请额外的领域专家加入。

1 月的讨论涉及以下多个技术议题：

Bootstrapping 循环问题 ：Rust 的引导构建（bootstrapping）目前依赖一个 Python 脚本（bootstrap.py）。如果 Python 将来开始依赖 Rust，就会形成一个循环依赖，届时需要想办法打破这个环。

Python 对象的内存安全建模：如何在 Rust 中安全地对附着/脱离 Python 线程的 Python 对象进行建模。PyO3 已经处理了这个问题，但其 API 较为笨拙，且存在一些健全性（soundness）边界情况。团队讨论了哪些语言特性可以在此提供帮助。

标准库链接问题：如何以不暴露可能造成符号冲突的方式，将 Rust 标准库构建和链接到 Python 扩展模块中。

链接参数差异化 ：在同一个 crate 中同时包含 bin 和 lib 目标时，如何为它们分别设置不同的链接器参数。

async 互操作 ：探索 Rust 的 async 机制与 Python 的 asyncio 之间潜在的互操作可能性。

大型 C 代码库中引入 Rust 的经验：讨论了将 Rust 引入大型 C 代码库所涉及的技术挑战与社会层面的挑战。Tomas 为此专门联系了 Rust for Linux 团队，Miguel Ojeda 分享了其将 Rust 引入 Linux 内核过程中的亲身经验与心得。

需要特别说明的是，这一切目前仍处于前期探索阶段。将 Rust 添加到 CPython 这一想法本身甚至尚未被正式提出 。这项工作的预期产出之一，是一份 Python Enhancement Proposal（PEP）------类似于 Rust 的 RFC 机制------正式提出这一方向。

五、cargo-script：距离稳定版仅一步之遥

这是作者最为期待的特性之一。Cargo script 允许你在单个 Rust 文件中直接声明依赖并运行它，可以将其理解为一种极度简化的 cargo run------无需创建整套包含 Cargo.toml 和目录结构的项目。

基础用法

最简单的形式如下：

rust 复制代码

#!/usr/bin/env cargo

fn main() {
    println!("Hello, world!");
}

（在稳定化之前，实际的 shebang 调用形式为：#!/usr/bin/env -S cargo +nightly -Zscript）

你可以通过 cargo hello-world.rs 运行它，或在将文件标记为可执行后直接执行 ./hello-world.rs：

复制代码

$ ./hello-world.rs
warning: `package.edition` is unspecified, defaulting to `2024`
   Compiling hello-world v0.0.0 (/home/example/tmp/hello-world.rs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `/home/example/.cargo/build/23/c81d708245acde/target/debug/hello-world`
Hello, world!

Cargo 会自动完成源码的编译并运行生成的二进制文件。

引入依赖：front matter

真正强大的地方在于引入依赖的能力。cargo script 能够解析一个"front matter"（前置元数据）区段，其格式是 Cargo.toml 的子集：

rust 复制代码

#!/usr/bin/env cargo
---cargo
package.edition = "2024"
[dependencies]
chrono = "0.4"
---

fn main() {
    use chrono::Datelike;

    let now = chrono::Local::now();
    let days_in_month = now.num_days_in_month();
    let last_day = now.with_day(days_in_month.into()).unwrap().date();

    println!("This month has {days_in_month} days and the last day is: {last_day}");
}

运行时，Cargo 会自动下载并编译依赖，然后执行脚本：

复制代码

$ ./hello-world.rs
    Updating crates.io index
     Locking 31 packages to latest Rust 1.93.0-nightly compatible versions
      Adding android_system_properties v0.1.5
      Adding autocfg v1.5.0
   [...]
   Compiling num-traits v0.2.19
   Compiling chrono v0.4.43
   Compiling hello-world v0.0.0 (/home/example/tmp/hello-world.rs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
     Running `/home/example/.cargo/build/23/c81d708245acde/target/debug/hello-world`
This month has 28 days and the last day is: 2026-02-28+01:00

除了作为"脚本"使用之外，cargo script 在构造最小可复现 bug 用例 和快速原型验证方面也非常出色。创建几个目录和一个额外文件表面上看起来没什么大不了，但在实践中，一个可以直接分享或内嵌在 Markdown 代码块中的单文件方案，带来的体验差距其实非常显著。

这一特性以各种形式存在了多年，如今（得益于 Ed Page 坚持不懈的推进）已经近在咫尺，即将登陆 stable 版本。

front matter 稳定化的曲折历程

将 front matter 纳入稳定化，需要先与 Style 团队就所有格式细节达成一致并完成实现。Style 团队确认一切就绪后，Tomas 与 Ed 进一步沟通，发现尽管 Style 团队这边已完成，front matter 稳定化 PR 却卡在了语言团队这边。

12 月初，Lang 团队提出了一个关于游离回车符（CR，\r）的顾虑：这些字符可能被渲染为换行符，但 Rust 工具链不会将其解释为换行，从而造成混淆。数天后，Ed 提交了一个对应的 PR，但该 PR 随后沉寂了数周，始终没有人回应。

Tomas 将此事提交给 Josh Triplett，并邀请 Ed 参加了一次 Lang 团队会议。会上，团队对这一问题进行了充分讨论，明确了请求的具体内容及其背后的技术原因，并就后续步骤达成了共识。Ed 按要求完成了修改，front matter 稳定化的最终评审期（FCP）已于数天前顺利通过。

cargo script 稳定化 issue 目前也已进入 FCP 阶段，且尚无任何异议。

六、crates.io 镜像与验证：建立透明的协作机制

尽管 Rust 生态支持替代注册表，但 crates.io 仍是绝大多数用户（以及 CI 等工具）下载 crate 时的首选来源。这对 crates.io 造成了较大的访问压力，同时也使部分用户面临无法可靠访问的困境------原因可能是带宽不足、网络不稳定，或是防火墙限制。

Linux 软件包生态早已应对过类似问题，大多数主流发行版都设有软件包镜像，用户通常不会直接访问原始源。这些镜像往往在地理上距离用户更近，也经常被企业 CI 系统作为内部缓存使用。

镜像面临的一个核心顾虑------尤其是在供应链安全日益受到重视的今天------是如何确保镜像提供的内容与 crates.io 完全一致：无论是镜像方本身还是传输过程中，都不存在任何篡改。

Walter Pearce 和 Josh Triplett 正在基于 The Update Framework（TUF）推进一套验证系统的建设，去年也已为此设立了专项项目目标。

这项工作虽然在持续推进，但除了少数几次会议之外，几乎缺乏对外的公开沟通。这让许多关注此工作并希望在其基础上构建功能的人感到受阻。该工作同样获得了基金会的赞助，但定期报告的频率和详细程度，难以满足 Rust 生态用户的实际需求。

为此，Tomas 专门组织了一次多方会议，参会者明确了各自的期望并达成了一致。以下是会议的几项成果：

将为这项工作提交一个 2026 年项目目标。
Walter Pearce 将担任联系人，负责定期发出进展更新。
Tomas 已建立一个双周同步会议，供相关人员持续跟进。
项目经理（Nurzhan 和/或 Tomas）将出席会议、整理会议记录，并确保更新内容对外发布。

这里有许多出色的工作正在推进，但需要共同努力让其成果真正可见。

七、值得关注：近期 Rust 相关文章汇总

Rust 基金会博文

Rust 官方博文

八、运营数据统计

以下数据由 Tomas Sedovic 整理，记录了项目经理角色自 2025 年 6 月启动以来的工作量情况：

指标	数值
会议记录总字数（6 月至 1 月）	323,000 字
出席会议总场次	40 场
1 月当月会议记录字数	57,800 字

1 月各团队会议的平均（均值）字数：

团队	平均字数
Cargo	1,900 字
Lang triage（语言团队 triage 会议）	6,700 字
Libs-API	6,900 字
Leadership Council（领导委员会）	3,200 字

原文作者：Tomas Sedovic，代表 Goals 团队发布。原文链接：https://blog.rust-lang.org/inside-rust/2026/02/11/program-management-update-2026-01/