Polonius 前世今生：Rust 下一代借用检查器的八年长路

作者： 张汉东 with KIMI K3.1 pro

执行摘要

• Polonius Alpha 于 2026 年 8 月 4 日在 nightly 默认启用，目标 2026 年内稳定。 拟稳定化的 Alpha 子集已无已知 soundness 问题，均值性能落入 10–20% 回归预算（top 10K 之外借用密集 crate 的尾部最差 2–3×，超出预算），可用 -Zpolonius=off 退出，beta/stable 不受影响（详见第 1、6 章）。

• 同一思想历经四次表述、三次缩减，Alpha 是 RFC 2094 愿景在 NLL 之后的又一次部分兑现。 被砍的从不是方向，而是"完整物化流敏感信息"的做法本身（详见第 2、3、7 章）。

• Alpha 的边界由工程可行性划定，恰与高频痛点重合：保留 problem case #3 等最高频借用检查误报，砍掉需在遍历内建模 kill 的模式（官方称剩余情形遇到的频率低得多）；新旧实现接受集互不包含（详见第 4、7 章）。

• 【推测】项目节奏或与少数关键人物的可用带宽有关：公开记录中的主要贡献者是一名连续 owner（lqd）、一名博士（Amanda Stjerna）与一位设计元老（Niko）；但人力是否为冻结、重启的主因并无官方出处，第 3 章把 2019–2022 的冻结归因于 datalog 路线的性能死路，二者不可混同（详见第 3、5、7 章）。

• Full Polonius 列入 Future 层，无负责人、无时间表，"Polonius 期货"梗或进入下一轮；若历史重演，它将以同样的渐进裁剪方式落地（详见第 6、7 章）。

1. 引子：2026 年 8 月 4 日发生了什么

1.1 公告本身

1.1.1 官方博客宣布 Polonius Alpha 在 nightly 默认启用，为"未来几个月稳定化"做准备；可用 -Zpolonius=off 退出

2026 年 8 月 4 日，Rust 官方博客刊发 Jack Huey 执笔的《Enabling the next iteration of the borrow checker on nightly》，宣布自当日起在 nightly 默认启用 Polonius Alpha——继 AST borrowck、NLL 之后的第三代借用检查器（borrow checker，验证引用合法性的静态分析组件）的可稳定化子集，为"未来几个月内的稳定化"做准备，目标"在年底前稳定"[1]。启用仅作用于 nightly，可用 -Zpolonius=off（rustc 参数、RUSTFLAGS 或 .cargo/config.toml）退出；公告给出的基线是：对拟稳定化的 Alpha 子集"没有已知遗留问题"，性能"总体达到可稳定化水平"[1-1]。

1.1.2 公告的三个目的：寻找未知性能回归、未预见的 unsoundness、诊断问题；反馈渠道为 GitHub issue #160456 与 Zulip

公告列出三重目的，本质是一次全生态公测：发现未知的严重性能回归、暴露未被预见的 unsoundness（错误接受不安全代码的分析缺陷）、收集需改进的诊断问题（"至今尚未观察到任何诊断变化"）[1-2]。反馈渠道为 GitHub 跟踪 issue #160456 与 Zulip 的 t-types/polonius 频道，退出者也被要求说明原因[1-3][2]。

1.2 流程工件链

1.2.1 MCP compiler-team#1015 的测试策略："启用并保持开启直到稳定化"，beta/stable 不受影响的技术手段

启用遵循编译器团队标准流程：MCP（Major Change Proposal，重大变更提案）compiler-team#1015 立项，启用 PR #159343 落地，博客对外公告[3][4]。MCP 确立"在 nightly 上启用并保持开启直到稳定化"的策略——借用检查问题更难发现，需要更长暴露窗口，出问题则"先在 nightly 禁用直至修复"[3-1]。为防默认行为泄漏到 beta/stable，MCP 给出三种手段：版本切割点两侧先禁用再重开、在 beta 分支中包含禁用逻辑、或在 is_next_enabled 中检测 nightly 通道[3-2]。

1.2.2 关键事实速览表

这张表揭示了公告的成色：它是在正确性债清零之后才启动的默认启用——最后一个已知 soundness 问题在公告前 25 天修复关闭，时间顺序是"修复落地→启用"，我们推断这是有意安排而非抢跑（推断，官方未明言）；退出通道与 beta/stable 隔离则为生态级回归这一最坏情形预留了可逆性，使默认启用成为可回退的试验。

1.3 为什么这件事值得写

1.3.1 Polonius 是 Rust 社区期待八年的"永远的期货"；problem case #3 是新手最高频的借用检查误报来源

Polonius 于 2018 年从 NLL（Non-Lexical Lifetimes，非词法生命周期，第二代借用检查器）工作中孵化，至公告已历时八年[1-8]。官方 2023 年 10 月的路线图写的是 "try to get Polonius on stable by Rust 2024"（尝试，并非承诺），最终未能实现[7]；Polonius 此后连续入选 2024H2、2025H1、2025H2 与 2026 四期 Rust Project Goals[8][9][10][11]，"Polonius 何时稳定"由此成为社区期货梗（社区说法，见第 3 章）。本次公告第一次给出有工程依据的期限：crates.io 前 10000 热门 crate 显著回归很少、最差约 21%，最差个案 2–3 倍，而团队接受预算为 10–20%（尾部 2–3 倍个案超出该预算）[1-9]。用户侧动力集中在 NLL 的 problem case #3：以get_mut_or_default（先查缓存、未命中则插入）为代表的条件返回引用模式，因 NLL 的流不敏感分析被误拒[1-10][12]，是官方论坛等渠道的高频借用检查误报，社区的变通方案（entry API、双重查找、polonius-the-crab）已沉淀为生态惯例[13]。

一个酝酿八年、反复许诺又跳票、直接命中最高频新手痛点的编译器组件，为何直到今天才走到稳定化门前？这一切要从第一代借用检查器说起。

2. 前世（一）：从 AST borrowck 到 NLL——Polonius 要解决的问题从何而来

Polonius 并非凭空设计：它所解决的每一个问题，都可以精确追溯到前两代借用检查器的具体技术决策。本章按"第一代 AST borrowck 的双重局限 → NLL 的理论革命与落地 → NLL 自身留下的精确技术缺口"三步还原这段前史，为第 3 章 Polonius 的诞生提供问题清单。

2.1 第一代借用检查器 AST borrowck

2.1.1 起源与技术特征：词法作用域而非控制流

AST borrowck 是 Rust 的第一个借用检查器实现，随 Rust 1.0（2015-05-15）一起稳定发布；其首次提交可追溯到 2012-04-26，Niko Matsakis 后来把这一天称作"borrow check 的生日"[14][15]。2022 年 NLL 稳定化 PR 的历史回顾明确写道："The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0."[14-1]

其技术特征可归纳为三点。第一，分析对象是 AST（后称 HIR）而非控制流图——rustc 开发指南指出"The borrow checker operates on the MIR. An older implementation operated on the HIR."[16]。第二，生命周期被绑定到词法作用域（lexical scope）：引用一旦存入局部变量，其生命周期就必须扩展为包住所有使用点的最内层语法块，配套规则是"变量的类型必须 outlive 变量的作用域"[17]。第三，对控制流只有近似建模：RFC 1211（MIR）承认当时的 CFG "is only an approximation of control-flow"，借用检查依赖 CFG 与 ExprUseVisitor 的组合[18]。这三点共同决定了它的诊断质量：旧检查器报错时会把借用结束位置指向函数末尾的 }，而非真正的冲突点[19]。

2.1.2 双重局限：误拒与误放

AST borrowck 的局限是双向的。一方面它误拒（false positive）大量安全代码——词法模型无法表达"引用在作用域结束前就不再使用"，由此产生四个经典 problem cases；Felix Klock 总结 NLL 的首要动机正是"让开发者写出更符合其对引用有效性直觉的代码"[20]。另一方面它误放（unsound）：Rust bug 库中有 8 个标记为 NLL-fixed-by-NLL 的 soundness bug（截至 2019 年 6 月，Felix Klock 统计）长期未修，涉及闭包捕获、控制流建模、对已 move 值的部分赋值（#21232 悬置四年多）等；由于官方已决意以 MIR borrowck 取而代之，开发者对这些 bug 的回应通常是"在 AST borrowck 中修复不可行/不值得"[20-1]。

表 2-1　Problem cases #1–#4 对照表[21][12-1]

表 2-1 揭示了一个关键事实：四个 problem cases 中，#1、#2、#4 都是"函数内"的控制流精度问题，NLL 通过把生命周期从词法作用域改为控制流图上的点集合即告解决；唯独 #3 涉及"借用随返回值逃逸到调用者"，其难点不在 region 的形状，而在 outlives 约束的作用范围——这一差别正是 2.3 节的技术核心。值得一提的是，#3 暴露的局限正是 HashMap::entry API 的设计动机之一[21-1]，可见借用检查器的表达力短板曾反向塑造了标准库 API 的形态。

2.2 NLL 革命：2016 博客三连 → RFC 2094 → 2019 全面取代

2.2.1 理论奠基：Niko Matsakis 的 2016 博客系列

NLL（Non-Lexical Lifetimes，非词法生命周期）的理论框架几乎全部在 Niko Matsakis 的个人博客 babysteps 上公开迭代成型。2016-04-27 的 introduction 一文区分了 lifetime（引用被使用的区间）与 scope（值被释放前的区间），并首次提出 problem case #1–#3[21-2]；2016-05-04 的第二篇给出两大核心思想——把生命周期定义为"控制流图中程序点（statement 级）的集合"、用 liveness（活性）分析决定变量类型必须有效的区间，并明确生命周期集合可以"有空洞"、不必连续[17-1]；2016-05-09 的第三篇引入 outlives 关系 'a: 'b，并论证它必须携带位置信息，写作 ('a: 'b) at P，否则约束会沿 CFG 边回流污染无关分支[22]。2017-02-21 的第四篇 "NLL using liveness and location" 基本定型：MIR 构建时擦除所有 region 再实例化为推断变量，以位置敏感的子类型约束 (T1 <: T2) @ P 做 DFS 传播[23]。这一"位置敏感的 subtyping"设想，是理解 2.3 节设计—实现落差的前提。

2.2.2 落地时间线：从 RFC 2094 到移除 migrate mode

表 2-2　NLL 落地时间线（2017–2022）

表 2-2 显示 NLL 的工程落地采取了罕见的过渡策略：migrate mode 最初同时运行新旧两个检查器，对"NLL 拒绝但 AST borrowck 接受"的代码只发警告而非报错，以此为存量生态留出迁移窗口；2019 年 8 月 AST borrowck 代码删除（随 1.40 发布）后，它退化为基于 NLL 结果的诊断模式[25-1][27-1]。这一过渡机制整体从 2018 年延续到 2022 年 8 月才最终移除；官方在 2022-08-05 宣布 NLL "fully stable"[27-2]。值得注意的是，1.40 的硬错误化不只是放宽——官方博客明确指出新检查器"还拒绝了一些当初只因旧检查器内存不安全 bug 才被接受的程序"，即同时兑现了修复 soundness 的承诺[26-1]。

2.3 NLL 的精确局限：flow-insensitive 的 outlives

2.3.1 "NLL 是 flow-insensitive 的"——一句需要精确化的简化说法

Rust 官方 2026-08-04 博客以 "NLL's analysis is flow-insensitive" 定性 NLL 的局限[1-11]，这是一个简化说法。精确的表述是：NLL 的 liveness 分析是 flow-sensitive（流敏感）的——变量在哪些程序点活跃由逐点的后向数据流分析决定，这正是 "non-lexical" 之名的来源；flow-insensitive（流不敏感）的是 outlives 约束的传播——整个函数只求解单一的全局 subtyping 关系，某条 'a: 'b 约束一旦由 MIR 类型检查在任何一点产生，就在传播阶段对整个函数生效。rustc 的实现以强连通分量（SCC）为粒度做不动点传播，约束产生时的位置信息在该阶段被丢弃[29]；Niko 本人 2023 年的表述更直白："In the borrow checker today, this graph is flow insensitive, meaning that there is one graph for the entire function."[30]

2.3.2 Problem case #3 的技术成因

上述局限的最著名受害者是 problem case #3——跨函数的条件控制流（条件返回引用）：

fn get_default<'r, K: Hash + Eq + Copy, V: Default>(map: &'r mut HashMap<K, V>, key: K) -> &'r mut V {
    match map.get_mut(&key) {
        Some(value) => value,               // 返回值 ⇒ 借用须活到调用者的 'r
        None => {
            map.insert(key, V::default());  // ^~~~~~ ERROR（NLL 误拒）
            map.get_mut(&key).unwrap()
        }
    }
}

与 #2 的本质区别在于：Some 分支把指向 map 内部的借用返回给调用者，于是 MIR 类型检查产生约束"get_mut 借出的 region 必须 outlive 返回类型中的 'r"。由于 outlives 传播是全局的，且 'r 是 universal region（全称生命周期参数）——其初始 liveness 覆盖整个函数体——两相叠加，get_mut 产生的 loan（借用）被推断为在全函数范围 in-scope，包括事实上不可能持有该借用的 None 分支；于是 insert 被判定为与活跃 loan 冲突而报错[12-3][1-12][29-1]。2026 年官方博客的总结一针见血：借用检查器"认为该借用活了整个函数（因为返回类型是 &'r mut V），尽管它在 None 分支根本不活跃"[1-13]。

2.3.3 被砍掉的设计与未厘清的实现史

problem case #3 并非 RFC 的疏漏，而是被有意放弃的既有设计。RFC 2094 原方案（Layer 4）是在 region 中加入 "end regions" 元素 end('r)，配合 2.2.1 所述的位置敏感 outlives 约束，逐点传播即可处理 #3；RFC 原文明确标注该部分"partially implemented"[12-4]。最终实现阶段该方案因分析效率过低被砍掉——ETH 博士论文（Prusti 作者 Vytautas Astrauskas）记载"the proposed analysis was too slow, and support for this example had to be removed"[31]；Niko 2019 年也承认完整接受范围未达成"既出于性能原因，也因为该公式化的灵活性不如预期"[32]。Inside Rust 2023 年 10 月的 Polonius update 给出官方定论："Issues like 'NLL problem case #3', issue #47680 and others, were therefore deferred from NLLs, and left as future work, Polonius."[7-1]

需要如实标注的开放项：RFC 2094 描述的位置敏感 DFS 传播算法是否曾在 rustc 历史版本中真正实现，至今没有定论。rust-lang/rust#145029（2025-08-07 开启，截至调研时仍开放）指出当前实现采用 SCC 连通图算法、"location information is largely ignored during the propagation phase"，并要求考证 DFS 传播"究竟是真正实现过、还是仅停留在原型/设计阶段"[33]。因此"NLL 实现偏离了 RFC 设计"这一叙述本身带有史料不确定性，本章按"设计为逐点、实现为全局"的最稳妥口径表述。

2.4 伏笔：NLL 未竟之事成为 Polonius 的验收标准

2.4.1 从遗留问题清单到项目目标

NLL 留下的问题清单在随后多年被逐字写入 Polonius 的各期官方项目目标：Rust 2024h2/2025h1/2025h2 项目目标均要求"nightly 上的 Polonius 实现通过 NLL problem case #3 并接受 lending iterators（rust#92985）"[9-1]。其中 #92985 是 #3 的循环内同构——用 GAT 编写 LendingIterator 的 filter 适配器时，循环中的 reborrow 与条件返回引用触发完全相同的全局 outlives 误拒[34]；#47680 则是 2018 年原型即已验证可接受的循环借用案例[15-1]。换言之，Polonius 的成功标准不是抽象的"更精确"，而是这份从 RFC 2094 时代起不断累积的具体问题清单。

时间上的衔接同样紧凑：就在 NLL 稳定化（1.31）前半年、migrate mode 尚未加入的 2018 年 4 月——借用检查器六岁"生日"的次日——Niko Matsakis 在 NLL 收尾期就开始了下一次实验，发表 "An alias-based formulation of the borrow checker"，把 region 从"程序点集合"重新定义为"loans 集合"[15-2]。这次实验就是第 3 章的主角：Polonius。

3. 前世（二）：Polonius 的诞生与八年困境

第 2 章已经说明，NLL 在 2018 年落地时砍掉了原 RFC 设想的 Problem Case #3（跨函数的条件控制流），并留下了 issue #47680 这类循环内借用的遗憾。本章讲述为弥补这些缺陷而诞生的 Polonius：它从一次 All Hands 会议后的实验起步，获得莎士比亚式的名字与一颗学术明星引擎，随后陷入八年性能困境，直到 2023 年一次范式转换才走出泥潭。故事的内核是一个技术命题：一个理论上更优美的公式化，如何被一个结构上无法消除的渐近开销拖垮。

3.1 2018：一次 All Hands 后的实验

3.1.1 从程序点集合到 loans 集合

2018 年 3 月底的 Rust All Hands（柏林）结束后，Niko Matsakis（NLL 的主要设计者、时任 Mozilla 研究员、Rust 核心团队成员）开始私下实验借用检查器的一种"替代公式化"（alternative formulation）。4 月 27 日，他在个人博客 baby steps 发表《An alias-based formulation of the borrow checker》，奠定了 Polonius 的理论基础[15-3]。博文提出的根本转向是：在 NLL 中，生命周期 'a 对应控制流图（CFG）上的一段程序点集合——即引用会被使用的时空范围；而在新公式化中，'a 被重新解释为一个 region（后改称 origin，后文沿用英文原名），即一个 loans（贷款，指 &x、&mut v 这类借用表达式产生的借用记录）的集合。若引用 r 的类型是 &'a i32，则违反 'a 中任何一笔 loan 的条款都会使 r 失效。借用检查的视角由此从"引用在哪里被用"（位置视角）翻转为"引用可能来自哪里"（别名/出处视角），故称 alias-based formulation[15-4]。

与之配套，子类型关系从 outlives 改为集合的 subset 关系（'a: 'b 意为 'a 的 loans 集合是 'b 的子集），而整个分析被写成一组 Datalog 规则——Datalog 是一种声明式逻辑编程语言，分析者只需声明输入事实（如 cfg_edge 控制流边、borrow_region 借用发生点、killed 借用被覆盖点）和派生规则，由求解器迭代计算最小不动点得出结果。关键改进是引入了活性（liveness）传播：subset/requires 关系只沿"后继点处仍活跃的 origin"传播，这使重新赋值旧变量的程序得以被接受[15-5]。

3.1.2 命名由来：御前大臣的忠告

4 月 27 日的博文尚未使用 "Polonius" 这个名字。5 月 1 日，GitHub 仓库 rust-lang-nursery/polonius 创建（API 记录创建时间为 2018-05-01T15:40:59Z），README 创建之初即写明命名出处[35][36]：名字来自莎士比亚《哈姆雷特》第一幕第三场中御前大臣 Polonius 赠别儿子的名言——"Neither a borrower nor a lender be"（既不要做借入者，也不要做借出者）。borrower、lender、loan 恰好全部是 Rust 借用检查的核心术语，一语双关。

Niko 本人把这个梗玩得很彻底。2019 年 10 月他在 Rust Belt Rust 会议的演讲标题即是对原句的反转改写——《Polonius: Either Borrower or Lender Be, but Responsibly》（要么借入要么借出，但要负责任）；幻灯片"名字哪来的"一页调侃道："冷知识：Polonius 曾是个经验丰富的 C 黑客，这让他格外谨慎。好消息：他后来改用了 Rust！——'借吧，贷吧，随便。编译器罩着你，去造你的梦吧！'——今天的 Polonius"[37]。至于"何时、由谁首次提议此名"，公开资料没有原始记录，只能夹逼在 4 月 27 日（博文未用名）与 5 月 1 日（仓库以该名创建）之间。

3.1.3 开局即巅峰：通过全部 NLL 测试

初始原型的表现堪称惊艳。2018-04-27 博文原文记录："我实现了这个分析的原型。它通过了全部 NLL 测试套件，还处理了一些当前 NLL 分析处理不了的案例——比如 #47680。然而，性能还有很长的路要走（它目前比现有分析慢）"[15-6]。也就是说，Polonius 在诞生的第一天就同时证明了表达能力上的优越性与工程上的不可用性；后一句坦白如同一句谶语，精确预言了此后八年的主线剧情。

表 3-1 解读：这张时间线最值得注意的密度——从想法公开、命名、建库、专属 Datalog 引擎问世到集成进 rustc，全部发生在 10 个月内，说明 Polonius 初期获得的社区资源与关注度是顶级的：datalog 领域最权威的人物之一为它专门写引擎，编译器团队为它开绿灯进 nightly。但也正是在这张表里埋下了全部隐患：4 月 27 日同一天，"通过全部测试"与"性能还差得远"同时成立——表达力问题一天解决，性能问题后来花了八年也没在 datalog 路线上解决。首篇博文便确立的"原型通过、性能欠费"结构，成为整个 legacy Polonius 时代无法挣脱的基本矛盾。

3.2 datalog 路线：datafrog、学术化与停滞

3.2.1 Frank McSherry 与 datafrog

初始原型构建在 differential-dataflow（增量数据流计算框架）之上。2018 年 5 月，Frank McSherry——differential dataflow 的作者、时任 ETH 系统组研究者（后任 Materialize 首席科学家）——专门为借用检查器团队写了轻量级嵌入式 Datalog 引擎 Datafrog，自述动机是"Rust 社区之前在用 differential dataflow，这非常勇敢，但一个更精简的 Datalog 实现眼下可能更合适"[38]。5 月 21 日他又追加实现 Treefrog Leapjoin——一种 worst-case optimal join（最坏情况最优连接）算法，针对 Polonius 中"一条规则连接三个关系只为求一个新程序点"的瓶颈规则，把 clap 基准单函数的分析时间从 7.692s 经 6.985s 压到 5.275s[38-1]。polonius 随即切换到 datafrog（PR #36），datafrog 后来移交 rust-lang 组织[39]；核心库拆分为独立的 polonius-engine crate，"同时供 rustc 与 polonius 使用"[35-1]。仓库提供三种算法变体用于对比实验：Naive（与博文规则一一对应）、DatafrogOpt（手工优化规则）、LocationInsensitive（丢弃位置维度的快速粗分析）[35-2]。

3.2.2 Amanda Stjerna 的硕士论文：学术化的高光与预言

2020 年，Uppsala 大学的 Amanda Stjerna（论文以旧名 Albin Stjerna 发表；她后来以博士生身份长期参与 rustc 的 Polonius 工作）完成硕士论文《Modelling Rust's Reference Ownership Analysis Declaratively in Datalog》。论文自称"据我们所知，Polonius 是 Datalog 首次被用于生产语言编译器的类型验证"，并给出了当时"对 Polonius 设计、实现与运行最完整的文字描述"[40]。实证研究覆盖 12 036 个公开 Git 仓库、3 939 171 个 Rust 函数（输入 facts 共 340 GB，单机跑了约两周），发现约 64% 的函数不含任何 loan，据此提出 Polonius 必须有"极低的启动开销"[40-1]。但结论章毫不留情："在 Polonius 能取代 NLL 之前，它需要在 facts 生成与求解两端都做大量性能改进……Rust 测试套件中不止一个测试在 Polonius 下因内存耗尽（OOM）而崩溃"[40-2]。2019 年 11 月的编译器团队会议纪要同样记录："修好了 rustc 测试套件的最后一个失败——但仍是上次那 2 个 OOM，我们还没时间看"[41]。OOM 与扩展性瓶颈的预言，此后被一再验证。

3.2.3 性能困境的本质：元组爆炸与急切求解

legacy Polonius 慢的根源是结构性的。其核心关系 subset(origin1, origin2, point) 与 requires(origin, loan, point) 都是带 CFG 位置维度的三元关系：origin 两两之间的子集闭包要在控制流图的每个点上分别物化并沿边传播，元组数量随 origin² × point（再加 origin × loan × point）爆炸，内存同步爆炸[15-7][40-3]。更根本的是，datalog 求最小不动点是急切（eager）计算——即使函数里根本没有借用错误，也必须把全部中间关系算完；而 NLL 的手写实现只在需要的约束路径上惰性遍历，天然避免了全量物化[42]。因此一切优化都只能压缩常数因子，无法消除公式化本身的渐近开销。

表 3-2 解读：这张表横跨 2018–2025 年，模式清晰：成功落地的优化（leapjoin、DatafrogOpt、Hybrid）改善的都是常数因子，而试图触碰根本的努力（换 Soufflé、重写引擎）全部烂尾。clap 单函数从 7.7s 到 5.3s 看似进步三成，但对标的 NLL 是毫秒级，差距仍是三个数量级；Hybrid 是最聪明的设计——用"无错快速放行"规避急切求解的浪费，但只对简单输入有效。用户侧数据点（nix 慢 11 倍、pulldown-cmark 十分钟）证明最坏情形从未被驯服；Stjerna 测得运行时与 CFG 边数、变量数强相关[40-5]，正是 origin²×point 结构性爆炸的直接体现。优化治标而公式化本身治本，这就是 2023 年官方换路线的技术判决。

3.2.4 2019–2022：冻结的仓库与积累的呼声

2019 年 11 月，wg-polonius 在同步会上决定"先完备性后性能"——性能优化主动让位，此后再未真正重启[41-1]。2021 年 8 月 Dylan MacKenzie（ecstatic-morse，MIR 数据流专家）做了最后一轮冲刺（leaper 缓存、reflexive 过滤、Soufflé 后端），随后归于沉寂：polonius-engine 的最后一个 release 停在 v0.13.0（2021-08-03）[47]，2022 年后仓库只剩 clippy lint 之类的琐碎 PR。-Zpolonius 一直钉在 nightly 上，但 Polonius Book 的状态页多年不变地写着"它尚未真正准备好被广泛使用"[42-1]；rustc 后来把这个 flag 改成 Off / Legacy / Next 三值枚举，datalog 版被标注为"历史值"——一个 flag 两个时代，是停滞期留下的化石层[48]。

与供给侧的冻结相对，需求侧持续累积：problem case #3 的跟踪 issue #54663 开单时报告人就注明"stable、nightly、nightly+NLL 全部失败，nightly+polonius 可以通过"[49]；2022 年 #92985 暴露 lending iterator filter 无法安全编写，成为 GAT 时代的标志性痛点（详见第 4 章）[34-1]；NLL-deferred、fixed-by-polonius 标签不断堆积。社区则发展出自己的应对：用户论坛上"用 nightly 加 -Zpolonius 就能编译"成为年复一年的安慰剂式回答；有人做了 polonius-the-crab crate，用宏与高秩生命周期技巧在稳定版模拟 Polonius 接受的 get_or_insert 模式，README 直接列着 #54663、#70255、#92985 作为动机[50]。"Polonius 何时稳定"逐渐成为社区期货梗：2022 年 HN 一篇讨论莎剧人物的《In Defense of Polonius》下，最高赞评论是"扫兴，我还以为是讲 Rust 新借用检查器的"[51]。旧 AST 借用检查器的代码早在 2019 年（1.40）已删除，2022 年 8 月 Rust 1.63 又移除了 NLL migrate mode，pre-NLL 检查就此彻底退场[27-3]——上一代已被火化，下一代仍无影踪，Polonius 此时已提出四年。

3.3 2023 转折：新公式化

3.3.1 放弃 datalog 引擎：子集约束图 + 活跃贷款数据流

转机来自一条看似无关的线索：Niko 等人在 a-mir-formality（Rust 语义的可执行形式化模型）中建模借用检查器时，尝试用 Polonius 风格重新表述现有 NLL，意外发现：现有 NLL 实现本身就是"location-insensitive（位置不敏感）的别名分析（子集约束图）+ 数据流传播的活跃贷款（active loans）"的组合——origin 仍是 loans 集合，但求法从 datalog 不动点换成了编译器教科书式的构件：活性分析、outlives 子集约束图、以及 gen/kill 式的活跃贷款数据流（发行时 gen 一笔 loan，当它不属于任何活跃变量的 origin、或其借用路径被覆盖时 kill）[30-1]。Rémy Rakic（lqd，NLL 工作组老将、编译器性能专家，后来的 Polonius 工作区负责人）用实验验证了这种重述与现有 NLL 行为等价："起初我们不确定它是否等价，但 lqd 用 rustc 测试套件做了实验验证，行为 100% 吻合"[30-2]。这意味着新公式化不需要推翻重写编译器，只需在 NLL 基础设施上原位扩展——官方 2026 年的回顾将其概括为"一种只需对现有 NLL 实现做最小重构的新公式化"[1-15]。

3.3.2 两层路线与七里程碑

2023 年 10 月 6 日，Inside Rust 官方博客发表 Rémy Rakic 与 Niko Matsakis（代表 Polonius 工作组）署名的《Polonius update》，正式官宣：当前计划不再使用基于 datalog 的实现，而是利用从中学到的东西在 rustc 内重写[7-2]。路线图刻意切成两层：第一步 location-insensitive loans-in-scope（"基于 Polonius 模型的 NLL"）只把 region 换成 loans 集合、子类型仍只算一次，行为与 NLL 等价、对用户是无操作，可以先落地替换内部数据结构；第二步 location-sensitive 把子集约束图按 CFG 每个程序点局部化（每个变量在每个程序点有独立 origin 变量），从而识别出某笔 loan 在 None 分支并不存活，真正通过 Problem Case #3[7-3][52]。博文列出七大里程碑：①剥离高秩约束处理；②location-insensitive 原型（当时已完成、PR 待合）；③通过全部 15000+ 测试与 crater（全生态编译测试）回归验证；④用新分析替换借用检查器组件；⑤location-sensitive 版上 nightly（藏在 feature flag 后）；⑥在 a-mir-formality 中建模；⑦location-sensitive 版稳定化——"希望在 Rust 2024 edition 中启用"[7-4]。

下面的流程图概括了本章所述的三种公式化的演进：

flowchart LR
    A["NLL（2015–2018）<br/>lifetime = CFG 程序点集合<br/>outlives 约束，惰性图遍历"] --> B["legacy Polonius（2018–2022）<br/>origin = loans 集合<br/>datalog 规则 + datafrog 急切不动点<br/>表达力达标，性能八年无解"]
    B --> C["新公式化（2023–）<br/>子集约束图 + 活跃贷款数据流<br/>原位扩展 NLL，分两层落地<br/>通向 Polonius Alpha"]

历史在这里出现了第一次重复：2018 年的博文以"性能还有很长的路要走"开启八年困境，2023 年的路线图则以"stable by Rust 2024"开启又一轮延期——这个承诺同样落空了——延期脉络详见第 5 章。但与 2018 年不同的是，这一次路线本身是对的：放弃 datalog 引擎、回到数据流分析的母体，使 Polonius 第一次拥有了通向稳定的工程路径。七里程碑中的前六项在随后三年里陆续推进——高秩剥离与 a-mir-formality 建模至今仍在收尾——最终收敛出第 4 章将要解析的 Polonius Alpha。

4. 今生（一）：Polonius Alpha 是什么——技术解析

2026 年 8 月 4 日，Rust 官方博客宣布在 nightly 上默认启用 Polonius Alpha——这是 2018 年从 NLL 工作中分离出来的 Polonius 项目，历经 legacy Datalog 实现的性能失败与 2023 年新公式化（new formulation，指不再依赖 Datalog 引擎、直接在 NLL 基础设施上扩展的重新表述）之后，第一个被官方认定为"可稳定"的分析子集[1-16]。本章回答三个问题：Alpha 相对 NLL 多接受了什么（4.1）、它在编译器内部如何实现（4.2）、以及它的边界与使用方式（4.3、4.4）。PR 时间线与工程推进过程留待第 5 章，本章只在必要时以 PR 号作锚点。

4.1 核心能力：flow-sensitive 的 outlives 检查

官方对 Alpha 的定位只有一句话：它启用而 NLL 不具备的，是对生命周期 outlives 关系的流敏感（flow-sensitive）借用检查[1-17]。第 2 章已论证：NLL 的 liveness（活性）分析是逐点的，但 outlives 约束（'a: 'b，由子类型关系派生）一旦被 MIR typeck 记录，就在传播阶段对整个函数全局成立。Alpha 补上的正是这块短板：同一条约束只在产生它的程序点生效，loan（借用，Polonius 模型中被跟踪的基本单元）因此可以"只活在它真正流动的分支里"。

4.1.1 最小示例 reborrow 与经典示例 get_mut_or_default（problem case #3）：NLL 拒绝、Alpha 接受

官方给出的最小示例如下[1-18]：

fn reborrow(a: &mut u8) -> &mut u8 {
    let b = &mut *a;
    if true { b } else { a }
}

let b = &mut *a 是一次重借用（reborrow）：从 a 再借出一个新的 &mut。在 if 分支返回 b，要求 b 的 loan outlive 返回类型的 region；NLL 把这条 outlives 约束当作全函数成立，于是认为 b 的 loan 在 else 分支同样存活，进而判定 else { a } 是在 loan 存活期间再次使用 a，报错。Alpha 把约束锚定在 if 分支的产生点，loan 沿 CFG 传播不到 else 分支的任何 live region，故接受[1-19][10-1]。

更常见的例子是 NLL problem case #3 的同构形态 get_mut_or_default[1-20]：

fn get_mut_or_default<'r, K: Hash + Eq + Copy, V: Default>(
    map: &'r mut HashMap<K, V>,
    key: K,
) -> &'r mut V {
    match map.get_mut(&key) {
        Some(value) => value,
        None => {
            map.insert(key, V::default());
            map.get_mut(&key).unwrap()
        }
    }
}

其被拒机制第 2 章已完整推导：Some(value) => value 把引用返回给调用者，产生"get_mut 借出的 region 必须 outlive 签名上的 'r"这一约束；全局约束叠加 universal region 'r 全函数 live，使该 loan 被认为在 None 分支也在作用域内，map.insert 因二次可变借用被拒[12-5]。Alpha 则知道这笔 borrow 在 None 分支并不 live，直接放行[1-21]。值得强调的是，RFC 2094 时代给出的 workaround（先 contains 再分支）之所以有效，是让借用在该分支根本不存在；Alpha 解决的是更难的情形——借用"存在，但在这条路径上已经死了"[12-6]。

4.1.2 lending iterator filter（#92985）同构解锁；GAT 时代 burntsushi 的"huge red flag"被拔除

rust-lang/rust#92985 是 problem case #3 在循环体内的同构版本：用 GAT（generic associated type，泛型关联类型）写 LendingIterator（lending iterator，每次迭代把从 self 借出的 item 借给调用者的迭代器）时，安全的 filter 适配器中 return Some(item) 同样是"循环内 reborrow + 条件返回引用"，NLL 同样误拒[34-2]。这一问题曾是 GAT 稳定化辩论中的标志性痛点——burntsushi 在 GAT 倡议的征求意见中直言："无法用安全代码为 LendingIterator 写出基本的 filter 实现，对我来说是一面巨大的红旗（a huge red flag）"[53]。GAT 倡议文档随后确认：修复它需要 Polonius[53-1]。在 Alpha 下，该模式已被明确标注 "This is now accepted"，对应测试 filtering-lending-iterator-issue-92985.rs 与 nll-problem-case-3-issue-*.rs 一并进入通过集[10-2][3-5]。换言之，这面"红旗"在借用检查层面被拔除；lending iterator 的剩余易用性问题属于 GAT 特性本身，与 Polonius 无关[10-3]。

4.2 实现架构：NLL 骨架 + region×point 统一图

Alpha 的实现哲学是"对现有 NLL 实现做最小重构"：不重写分析，而是复用 NLL 的 MIR、活性分析、loans-in-scope 数据流与非法访问检查，只替换约束求解这一核心环节[1-22][54]。

4.2.1 约束锚定在产生点；liveness 边按 variance 定向（前向/后向/双向）；bidirectional edges 编码 invariant 相等

Alpha 的分析建立在一张统一图（unified graph）上：节点是 "region r at point p"——即 region 与 MIR 程序点的笛卡尔积，每个变量在每个程序点有独立的节点[10-4][54-1]。图上有两类边：

• typeck 边：outlives 约束 r0 ⊆ r1 @ p 加在**约束产生的点 p**，允许 loan 在同一点内从 region 流向 region。这是 location-dependent outlives 约束——NLL 中同样的约束是全函数一份[10-5]。

• liveness 边：若 CFG 有边 p→q 且 region 在 q live，则在相邻点的同名 region 节点间加边，允许 loan 跨点流动。边的方向由 variance（型变）决定：covariant 前向、contravariant 后向、invariant 双向[54-2]。

bidirectional edges（双向边）专门编码 invariant（不变）关系：&mut T 对 T 是 invariant 的，赋值要求两侧 origin 相等，即 'a: 'b 与 'b: 'a 同时成立，在子集图上表现为双向边[54-3][52-1]。其代价是 loan 可以"时间倒流"——沿双向边逆流到 CFG 中更早的点再顺流而下，把本不该冲突的位置也标记为 live。这是 Alpha 精度损失与正确性讨论的焦点，需要靠 kill 信息与活性信息事后消去[52-2]。

4.2.2 "可达性近似 liveness" + 沿用 NLL loans-in-scope 处理 kills；Alpha 在遍历中移除 kill 处理（PR #143093）

在统一图上，Alpha 用一条近似规则判定 loan 活性：loan l 在点 p live，当且仅当 l 能从其引入节点到达某个在 p live 的 region 节点——即以"子集图 + CFG 上的可达性"近似真正的 liveness[10-6]。定型 PR #143093 的关键简化是遍历过程中不再处理 kill（kill 指 place 被覆写导致 loan 失效的事件）：遍历只检查"是否到达 live region"，到达即记为 live；kill 仍由后续与 NLL 完全相同的 loans-in-scope 数据流计算兜底[55]。该 PR 自述：这是"一个处理 NLL problem case #3 及更多的 polonius alpha 分析，但仍使用更快的'以可达性近似 liveness'和与 NLL 相同的 loans-in-scope 计算——因此不像 Datalog 实现那样处理完全的流敏感性"[55-1]。取舍是刻意的：损失一部分精度，换来一个简单、可行动（actionable）、且最坏情况只是误报而非 unsound 的原型[55-2]。

4.2.3 placeholder/higher-ranked 问题通过改写为 'static outlives 约束从主路径剥离（PR #123720 落地、#130227 搁浅）

higher-ranked（高阶）生命周期中的 placeholder region 原本是 region inference 阶段的特判对象（universe 检查 / leak check）。为了让 Alpha 的局部化子集图无需理解 placeholder/universe 概念，PR #123720 把"universe 泄漏的 placeholder"统一改写为 r: 'static 形式的普通 outlives 约束，将这一复杂度从主路径剥离，该 PR 已合并[56]。更激进的 PR #130227 试图彻底移除 placeholder 的所有特殊处理、代以前置改写步骤，但因与 trait solver 后续开发冲突而停滞，该 PR 已于 2026-01-22 未合并关闭，后续改以拆分的小步重构继续（如后继 PR #140737）[57]。

4.3 Alpha 的边界：它不是完整 Polonius

4.3.1 链表 cursor + 条件 reborrow 仍被拒（与 NLL 同样的不精确）；Alpha 与 legacy 的接受集互不包含

官方给出的反例如下——它在 legacy Polonius（Datalog 原版）下通过，在 Alpha 与 NLL 下同样报错[1-23]：

struct X { next: Option<Box<X>> }
fn conditional() {
    let mut b = Some(Box::new(X { next: None }));
    let mut p = &mut b;
    while let Some(now) = p {
        if true {
            p = &mut now.next;
        }
    }
}

失败机制（2025h2 目标文档标注为"与 NLL 同样的不精确"）：reborrow p = &mut now.next 只发生在条件分支内；完全的流敏感性要求区分"没走该分支的循环路径上新 loan 不存在"与"走了分支的路径上旧 loan 被 place 覆写 kill"两种情况。而 Alpha 的 loan liveness 是可达性近似、遍历中不看 kills：loan 一旦能沿 liveness 边绕循环回到 live region，就被当作在所有可达点 live，路径区分被抹平[10-7]。对照实验进一步圈定了边界：无控制流的无条件 reborrow、以及经间接路径的条件 reborrow 仍被接受——因为这两类的 kill 由 NLL 的 loans-in-scope 计算正确处理；唯独"条件产生的 reborrow + kill 需要在图遍历内建模"这一组合超出 Alpha 能力[10-8]。另一个方向同样存在：官方确认也发现了"Alpha 能编过而 legacy 不能"的程序，因此 Alpha 并非 legacy 的子集，两者在接受集上互不包含[1-24]。

表 4-1　NLL、Polonius Alpha 与 legacy Polonius 三方对照

解读：这张表揭示了 Alpha 的真实定位——它不是 legacy 的"加速版"，而是精度与性能的折中产物。在公式化上，Alpha 与 legacy 共享"origin 是 loan 集合"的 Polonius 模型，但求解方式截然不同：legacy 逐点物化全部子集关系，换来完全流敏感，代价是性能失控、多年优化无果[1-25]；Alpha 用图可达性近似 liveness、并把 kill 处理留给 NLL 既有数据流，均值性能落在可接受区间（尾部个案除外），代价是链表 cursor 这类需要"遍历内建模 kill"的模式退化为与 NLL 相同的不精确[10-9][55-3]。对绝大多数用户而言，Alpha 拿到了收益最大的那块——problem case #3 与 lending iterator——这正是官方称它"解决了最常见的借用检查痛点"的原因[1-26]。但表中最后一列提醒：legacy 能过而 Alpha 不能、Alpha 能过而 legacy 不能的案例都已确认存在，二者互不包含，"Alpha"之名正是对这一非完备性的明示[1-27]。

4.3.2 诊断影响：因 Alpha 做的工作 ≥ NLL + boring-locals 对齐（#136299），官方称"尚未看到诊断变化"

启用新检查器最大的用户可见风险是诊断回归。官方博客明确表示："我们尚未看到任何诊断变化"[1-28]。机制上有两层保障：其一，Alpha 在 NLL 骨架上扩展，官方说法是其做的工作不少于（≥）NLL；它接受更多程序，因此并不意味着"报错集合不变"，但错误仍由同一套"loans in scope ∩ invalidations"机制与同一套 explain_borrow 诊断基础设施产生，目标文档据此预期"几乎没有诊断回归"（新增的错误仍可能需要改进诊断）[10-10]；其二，专门的诊断对齐工程早已完成：PR #136299 修复了约 80 处 Alpha 与 NLL 的诊断差异。其核心是 "boring locals"（类型中只含无 outlives 约束的自由 region 的局部变量）——NLL 不为它们计算 liveness、因此它们不会出现在错误解释中，而 Polonius 没有这一优化会把它们算进去；该 PR 记录 NLL 视角的 boring locals 并在生成解释时忽略，使两边诊断逐条对齐[58]。

4.4 如何使用

4.4.1 -Zpolonius=next/off/legacy 三值含义；nightly 默认启用；退出方式（rustc flag/RUSTFLAGS/.cargo/config.toml）

rustc 的 -Zpolonius 选项为三值枚举[48-1]：

表 4-2　-Zpolonius 选项取值

解读：三个取值对应 Polonius 的三种存在形态，理解它们是阅读社区讨论的前提。legacy 是 2018 年起的外部 Datalog 原型，挂接在 rustc 上多年，能验证 Polonius 模型的表达力上限，但官方已明确其"不可扩展、无稳定化路径"，如今主要用于对照实验[10-11]；next 是本章的主角，2025 年 8 月定型后长期需要显式开启，2026 年 8 月 4 日起成为 nightly 默认[1-29][3-6]；off 是退出开关。需要特别注意作用范围：默认启用只影响 nightly toolchain，beta 与 stable 均不受影响，若某个 nightly 出现问题，官方可在 beta 分支直接关闭[3-7]。退出方式有三：rustc -Zpolonius=off、环境变量 RUSTFLAGS=-Zpolonius=off，或在项目 .cargo/config.toml 中配置 rustflags = ["-Zpolonius=off"][1-30]。遇到问题可在 tracking issue rust-lang/rust#160456 或 Zulip t-types/polonius 频道反馈[2-2]。

5. 今生（二）：从项目目标到 nightly——2024–2026 工程推进与验证

第 4 章解析了 Polonius Alpha 的技术形态；本章回答一个工程问题：一个 2023 年承诺"2024 年稳定"的特性，如何在四期 Rust 项目目标（Project Goals）的滚动管理下，于 2026-08-04 才默认登上 nightly。本章以项目目标文档、tracking issue 与官方博客为时间轴，还原推进过程、关键人物与验证证据。

5.1 四期项目目标时间线

5.1.1 四期目标对照

Rust 项目自 2024 年起以半年为一期设立公开的项目目标。Polonius 在 2024h2 至 2026 连续四期均有独立目标、且四期 owner 从未更换（唯一连续 owner）；其 tracking issue（rust-lang/rust-project-goals#118）自 2024-07-22 创建以来贯穿四期，是唯一连续的官方进度档案[59]。

解读：四期目标的命名本身即是一部收缩史。2024h2 与 2025h1 使用完全相同的名称，说明第一期严重低估——原定六个月内完成的 "land on nightly" 实际跨期一个季度以上才完成。2025h2 升格为旗舰目标，但名称中的关键词从 "Scalable" 换成了 "Stabilizable"，对应目标文本中的坦白："this revision of the analysis, while less powerful than we hoped"[10-13]——团队正式接受交付一个能力弱于完整 Polonius、但可落地的子集。2026 期则首次把 "Stabilize" 写入目标名，并捆绑 a-mir-formality 形式化建模与 Rust Reference upstreaming，说明验收标准已从"代码能上"升级为"行为可被编译器之外的形式规范所定义"[11-2]。四期 owner 均为 lqd，保证了执行连续性；评审阵容由 Michael Goulet 换为 Jack Huey，Jack 同时出任新设的 types champion，与 types 团队投入加深的节奏一致。

5.1.2 关键 PR 链

推进主线可概括为六个节点。落地系列：2024 年底至 2025 年 1 月，lqd 以 #134268 "Foundations of location-sensitive polonius"（2024-12-22 合入 1.85.0，matthewjasper 评审）为首的 8 个 PR 将 location-sensitive 原型全部落地 nightly[60]。诊断对齐：#136299（2025-02-04）忽略 NLL "boring locals"，一次修复约 80 处与 NLL 的诊断差异[58-1]。Alpha 诞生：#143093 "Simplify polonius location-sensitive analysis"（2025-06-27 开、2025-08-10 合入 1.91.0）把不可 scale 的完整 location-sensitive 分析重构为以可达性近似活性的 alpha 分析，全测试套件通过、crater 无回归[55-4]。性能优化：#149639（2026-01-23）修正 typeck 约束计算方向，wg-grammar 基准上该项提速 20 倍、端到端 -15%[61]；#150551（2026-02-13）将 localized outlives 约束改为遍历时惰性计算，合入后最差基准仅剩 +5~6% wall-time，lqd 据此宣布 "feels stabilizable"[62]。soundness 收官：#156027（Jack Huey，2026-07-10 合入）修复 opaque type region liveness 问题（issue #153215），为 nightly 默认启用扫清最后障碍[5-1][6-1]。

5.1.3 延期脉络

官方对延期的承认异常直白。2023-10 的 Inside Rust 博文曾给出 "a roadmap to try to get Polonius on stable by Rust 2024"[7-5]；2026-08-04 公告则回顾："We had hoped, to try to stabilize this new formulation in 2024; but, various things popped up that delayed this."[1-32] 从月度记录可还原三次主要滑期：其一，2024 下半年 location-sensitive 重写远超预期（mid-point off-by-one 错误、"time-travel/backwards edges" 迫使放弃 kills 方案、数百个 UI 测试失败），"land on nightly" 延至 2025 年 1 月底[59-3]；其二，2025 年 6 月 crates.io 压测发现单个 dataflow 函数耗时 40 秒级，完整流敏感分析根本不可 scale，团队砍范围改做 alpha 近似[63]；其三，Alpha 落地后残余 UI 失败被证实是一个与新 trait solver 的 opaque types 问题纠缠的 soundness 缺陷，叠加 #149639/#150551 两轮性能补课，又耗去约半年[59-4][57-2]。承诺文本逐级后移：2025h2 公告只敢说 "ready for stabilization in 2026"[64]，2026-08-04 公告最终落在 "stabilize prior to the end of the year"（2026 年底前）[1-33]。从 2023 年的"2024 稳定"算起，累计滑期约两年。

5.2 关键人物群像

5.2.1 Rémy Rakic（lqd）：唯一连续 owner

Rémy Rakic 是编译器团队贡献者、compiler performance 与 Polonius 工作组成员，更是 2018 年 NLL 工作组时代的老兵；2013 年起关注 Rust、2016 年起贡献[65]。2023 年他完成了新公式化的等价性验证与首个 location-insensitive 原型，自此成为 Polonius 的事实负责人：四期项目目标的唯一连续 Owner、tracking issue #118 月度评论的主要作者（该 issue 另有 nikomatsakis、tomassedovic 等人评论），location-sensitive 原型、Alpha 重构（#143093）与两轮性能优化（#149639、#150551）的主要作者。2024 年他获选 Rust Foundation Project Fellowship，fellowship 年度的工作重心即 2024h2 目标[65-1]。

5.2.2 设计、评审与新生力量

Niko Matsakis（Rust 语言设计者之一、types 团队资深成员）四期目标均列为 Polonius 工作组与设计领导者，2025h2 期负责 Design review[10-14]。Amanda Stjerna（Uppsala 大学博士生，硕士论文即做 Polonius，此后近乎全职投入，EuroRust 2024 曾作 Polonius 六年史报告[66]）负责 higher-ranked/placeholder 方向：#123720 为 Polonius 铺路，但大型重构 #130227 因与 trait solver 演进冲突于 2026-01-22 未合并关闭；她另有两篇在写论文（一篇论现有借用检查器、一篇论 Polonius）[67][57-3]。Jack Huey（types 团队）的角色随时间升级：2024 年底落地系列的主要评审 → 2025h2 旗舰目标的 types champion → 2026 年亲自修复最后的 soundness 问题（#156027）并执笔 nightly 启用公告[6-2][1-34]。Matthew Jasper 与 Michael Goulet 分别为四期与前两期目标文档列名的评审人[8-2][11-3]。此外，tiif 推进 opaque types implied bounds 重构（#152051，soundness 修复的支撑工作）并与 Niko 做 a-mir-formality 建模；硕士生 Tage（tage64，Amanda 指导）留下懒惰分析原型 #141326 与 bitset 系列，其遗留正确性问题 2026 年由 Amanda 检视、由 James 在 #157024 继续[59-5][57-4]。

5.3 验证现状：性能与正确性

5.3.1 性能数据分层口径

由于 Alpha "做的工作大于等于 NLL"[1-35]，性能是稳定化的头号验收项。官方可接受预算为 10–20% 编译开销（2026 目标的 design axiom "Accept bounded cost"）[11-4]。历次测量口径各异，须分层阅读：

解读：四组数字并不矛盾，差异完全来自口径。函数级扫描暴露的是病理个案（+60%），crate 级均值则被大量小 crate 稀释（+1.4%）；全量编译含依赖、leaf 只测 crate 自身，故超标 crate 数（91 vs 61）不可互比；p99.9 的 36% 与"最差 2.5×"则提醒长尾仍然陡峭。三点结论可跨口径成立：均值回归（1.4%–2%）远低于 10–20% 的官方预算，但尾部（p99.9 的 36%、最差 2.5×、top 10K 之外的 2–3×）超出预算，其发生频率要靠监控窗口确认；最差 case 高度集中于"巨型函数 + 海量 loans"的形态，官方甚至顺势给出工程建议 "Small composable functions is still good advice"[57-6]；博客与 MCP 的大规模 crate 测量均出自团队自建管线（rustc-perf 套件的约 2% 均值除外），阈值（1% + 30 秒以下二次缩放）是自认的 arbitrary 标准，引用时必须带口径。团队判断现有结果"不会阻止 nightly 默认启用，甚至按现状稳定化"[59-7]。

5.3.2 正确性

Alpha 稳定化前最后一个已知 soundness 问题是 issue #153215：free region liveness visitor 只把"被 opaque type outlive 的 region"标为 live，而忽略"outlive 它的 regions"；对 NLL 无害，但 Alpha 依赖 liveness 传播 loans，全 dead 的情形会漏报 illegal access 错误[5-2]。该问题与新 trait solver 的 opaque types 缺陷（trait-system-refactor-initiative#159）同根，tiif 的 #152051 提供支撑，最终由 Jack Huey 的 #156027 于 2026-07-10 合入修复，issue 随之关闭[6-3]。2026-08-04 官方口径为：对拟稳定化的 Alpha 子集 "there are no known remaining issues"[1-37]。需注明，Alpha 与 legacy datalog Polonius 的接受集互不包含（各有对方不能编译的程序），这是已声明的精度边界而非 soundness 缺陷[1-38]。

5.3.3 验证体系

验证采用多层冗余。crater（全生态编译测试）自 2025 年 6 月起多轮运行均未发现 Alpha 引入的回归；但须注明覆盖缺口——2025-08 Alpha 落地时，crater 基础设施自身约有四分之一的 crate 无法测试（与 Polonius 无关），"无回归"结论是在此缺口下作出的[55-5]。compare-mode：compiletest 支持 --compare-mode=polonius 对全量 UI 测试双跑比对，但 dev-guide 承认 compare-mode 此前不在 CI 中强制执行[68]。这一缺口由专用 CI 阻塞任务补上：MCP #996 获批后新增 x86_64-gnu-next-trait-solver-polonius 任务，在 PR 与合入 CI 中阻塞性运行 polonius compare-mode 全量 UI 测试——其动机原文是回归"已经两次在无人察觉时发生"[69]。测试资产方面，tests/ui/nll/polonius/ 目录约 65 个测试文件，覆盖 NLL problem case #3 的十个历史 issue 变体与 lending iterator 等场景；Alpha 不处理的完整流敏感 case 以 known-bug 形式显式存档[70]。最后，a-mir-formality 正被改造为可分别建模 NLL 与 Alpha 的形式化 oracle，2026 目标要求将该模型 upstream 进 Rust Reference——这将使 Polonius 成为"首个行为在编译器之外被规范定义的借用检查器"[11-5][71]。

6. 到哪里去：稳定化路径与完整愿景

第 5 章梳理了 Polonius Alpha 的工程推进与验证现状，本章回答一个更向前看的问题：从 2026-08-04 nightly 默认开启出发，这条路具体怎么走、走到哪里算终点、以及终点之后还剩下什么。需要预先声明方法论立场：本章涉及未来的论断一律区分"官方承诺"（有博客、项目目标文档或 roadmap 原文支撑）与"推测"（基于发布节奏、流程惯例或措辞的推算），推测处均显式标注。

6.1 稳定化路径与时间表

6.1.1 剩余工作：监控反馈、修性能回归、内部文档、稳定化报告

官方承诺非常明确。2026-08-04 博客在 "What's next" 一节列出了稳定化前的全部剩余工作："Over the next few months, we will be monitoring Github and Zulip for any reported issues about Polonius Alpha. We will also be working to address known performance regressions. Finally, we will be working on internal documentation about the implementation. All prior to stabilization. Then, we are aiming to stabilize prior to the end of the year!"[1-39] 即四项任务——监控 GitHub/Zulip 反馈、修复已知性能回归、编写内部实现文档、准备稳定化——之后，目标是 2026 年底前完成稳定化。配套机制均已就位：MCP #1015 确立了"在 nightly 上保持开启直至稳定化"的测试策略，并预留了出现问题时在 beta 分支禁用或按 channel 检测的兜底方案[3-9]；tracking issue rust-lang/rust#160456 负责集中收集 nightly 反馈；-Zpolonius=off 提供退出开关[1-40]。

下表汇总稳定化前的剩余工作及其截至 2026 年 8 月的状态：

解读：这张表的信息密度在于它揭示了 Polonius 稳定化区别于常规特性的两个特殊点。其一，最难的"守门项"（soundness 修复）实际已在 nightly 启用之前完成，剩余四项全是"时间换确定性"的工作——监控窗口的长度而非技术难度决定了时间表，这正是官方敢于给出"年底前"承诺的底气。其二，稳定化报告所要求的 Reference 文档更新，对 Polonius 而言不是写一篇说明文字，而是交付一个形式模型（见 6.2 节），流程负担比常规 feature 重，也构成了时间表上最不可压缩的一段。性能项则处于"有预算、有数据、有退路"的舒适区：官方愿接受 10–20% 编译期开销，均值实测远优于预算（尾部个案除外），因此性能回归更可能拖慢而非阻断稳定化。

6.1.2 版本推测：1.101 或 1.102

【推测，非官方承诺】官方只承诺"2026 年底前稳定化"，未指定任何版本号[1-44]。按 Rust Forge 发布列车（6 周一版）：1.99 stable 为 2026-10-01，1.100 为 2026-11-12，1.101 按节奏推算约在 2026-12-24[73]。要赶上"年底前"，stabilization PR 最可能落入 1.101：1.100 的 beta cutoff 在 2026-09-25 前后，距 nightly 启用仅约七周，不足以容纳"数月监控 + 修复 + 报告 + FCP"；1.101 的 cutoff 约在 11 月上旬，与博客"未来几个月"的措辞吻合。若反馈期暴露问题，则滑入 1.102（2027 年 2 月）。另需注意：若"年底前稳定"仅指 stabilization PR 在年底前合入（而非 stable 发布），则 11 月上旬 cutoff 之后合入的 PR 将落在 1.102。此推断置信度为中——纯基于发布节奏推算，任何一方（lang 团队决策、突发 unsoundness）都可能改写。

6.2 形式化：目标是首个写入 Rust Reference 的借用检查算法

6.2.1 a-mir-formality 建模与 upstream 进 Reference

2026 项目目标 "Stabilize and model Polonius Alpha" 把形式化列为与稳定化并列的交付物："Build a formal model and specification of the borrow checking analysis in a-mir-formality, and upstream it into the Rust reference. This ties into the experimental language specification goal as a case study for integrating formal models into the specification process."[11-8] 其直接前身是 2025H2 目标 "Borrow checking in a-mir-formality"——当时模型尚无任何借用检查表示，半年内完成了 MiniRust 集成、MIR type checker 与 Polonius Alpha 关键部分的建模[74]。具体进展由 2025-12 月报逐周记录：PR #206 提交 NLL 规则"第一稿"（检查 loan 违例与 outlives 要求），PR #207 加入 &mut 支持并新增 NLL problem case #3 测试，PR #210 引入 feature gates 并重构 type checker 以使 outlives 可流敏感——这是迈向 Polonius Alpha 建模的关键一步[75]。

该工作与同期目标 "Experimental language specification"（基于 Reference 分支 + 稳定性标记的 nightly 规范实验）形成联动："This goal will collaborate with the goal to integrate a-mir-formality into language specifications, though neither goal will block on the other"[76]；另有目标 "Expanding a-mir-formality to work better as a Rust type system spec" 探索从"Reference 链接到 a-mir-formality 规则"到"将形式规则嵌入 Reference 正文"的多种集成形态[77]。其历史分量在于：Rust 长期没有正式规范，借用检查器的"接受/拒绝"语义此前从未被任何官方文档完整描述——lang 团队 2022 年规范讨论中甚至出现过"借用检查细节留给 cargo check、不在规范中写明"的选项[78]。Polonius 的 origins-as-sets-of-loans 模型第一次提供了可在纸面上书写的算法级规范对象。

6.2.2 学术闭环：从 RustBelt 到 RustCompCert

a-mir-formality 的 upstream 不是孤立事件，而是一条八年学术链的收束。RustBelt（POPL 2018）在 Iris/Coq 中建立了 λRust 语义模型与 lifetime logic，但建模的是 NLL 之前的借用检查；Ralf Jung 的研究计划书早已把 Polonius 列为直接验证对象[79]。Oxide（2019/2021）则自认与 Polonius 共享"区域=贷款集合"视角，"we feel that Oxide corresponds to a sort of type-systems formulation of Polonius"[80]。a-mir-formality 把这条线引入官方工程流程（作为 oracle 验证 rustc 实现、作为留存规范）[11-9]；而 2026-02 的 RustCompCert（arXiv:2602.07455）在 CompCert 的 Kildall 数据流框架中对基于 Polonius 的借用检查做了机器验证，指出"Polonius can be seen as an alias analysis, which is more suitable to implement in the program analysis framework provided by CompCert"[81]。人员纽带上，Amanda Stjerna 正撰写两篇论文——一篇关于当前借用检查器、一篇关于 Polonius 工作——作为其博士研究的组成部分（2026 年初官方月报确认在写，发表状态未知）[57-7]。按目标，"工程实现 ↔ 形式模型 ↔ 规范文本 ↔ 机器验证"的闭环将首次在一门生产语言的核心分析上成形（Reference upstream 尚未完成，a-mir-formality 建模仍在收尾）。

6.3 Alpha 之后：The Borrow Checker Within roadmap

6.3.1 分层愿景表

Alpha 的稳定化不是路线图终点，而是官方明确的"地基"。2026 项目目标九大 roadmap 之一 "The Borrow Checker Within"（联系人 Niko Matsakis）写道："Polonius alpha is the foundation — it fixes the borrow checker's analysis to correctly handle conditional borrows and lending iterators, which is prerequisite engineering for everything else."[82] 下表整理该 roadmap 的分层路线：

解读：此表最关键的读法是注意"时间"列的不对称——只有 2026 年的两层有承诺，其后四层全部标注 "Future" 且无任何负责人或日期。层级之间存在严格依赖：roadmap 原文强调这些变更层层相叠，Niko 在 2024 年的同名博客中将其归纳为四个问题的解法链——"条件返回的引用由 Polonius 解决"，其余依次由显式生命周期语法、view types、内部引用解决[83]。这意味着 Alpha 的稳定化只是解锁了"入场券"：Full Polonius 处理的链表条件重借模式（官方博客给出的 while let Some(now) = p { p = &mut now.next; } 例）在 Alpha 下仍不能编译[1-45]，而自引用结构体这一 Rust 用户最长期的诉求位于链条最末端。社区期待的"完整 Polonius"，在官方文档中实际上被拆成了四个独立特性，每一个都需要自己的设计、RFC 与实现周期。

6.3.2 官方明示：Alpha 稳定后暂停 feature work

与愿景表同样重要的是官方的克制声明（verbatim）："we don't currently have any concrete plans to continue active feature work on the Polonius implementation after the stabilization of Polonius Alpha … given that Polonius Alpha solves the most-encountered borrow-check issues, we are shifting our time to other high-priority work for the near future."[1-46] 官方明示的原因是：Alpha 已覆盖最常见、影响最大的借用检查问题（NLL problem case #3 与 lending iterator 模式），剩余情形（完全流敏感）出现频率低得多，边际收益递减[1-47][11-10]。此外还有两点并非官方明示、属推断：其一，人力约束——月报中 lqd 自述可支配时间减少、Jack Huey 分担[57-8]，但是否为暂停的原因官方未说明；其二，types 团队同期承担 next-gen trait solver 稳定化等旗舰工作[84]，这只是同期事实，优先级挤占的因果为推测。影响（推断，标注）：roadmap 上四层 Future 特性在可预见的周期内不会有实质推进，"完整 Polonius"很可能成为继"Polonius 何时稳定"之后的下一轮社区期货；针对 Alpha 不覆盖场景的 polonius-the-crab 这类 unsafe polyfill 仍有存在价值[85]。唯一官方承诺的后续投入是性能优化——"Performance work can also be done by others, both before and after stabilization"[11-11]。

6.4 生态外溢

6.4.1 gccrs 与替代实现的一致性基准

Polonius 的影响已越出 rustc。gccrs 采取"复用而非重写"战略：通过 FFI 调用 Rust 编写的 polonius 引擎（源自捷克理工大学的硕士论文原型，BIR + C ABI），官方博客明言目的是"help ensure that the results we produce will be equivalent to rustc"[86]；2025-03，约 145 个 gccrs 补丁并入 GCC 15，Phoronix 标题即 "Lands The Polonius Borrow Checker"[87]。由此出现一个值得记录的对称：rustc 内部的 Alpha 是原生重写（不走 polonius-engine crate），而 gccrs 走的是 FFI 复用 legacy Datalog 引擎的路线——两条实现路径并存。此时 §6.2 的 Reference 规范化获得了第二层意义：它（一旦完成）将为 gccrs 乃至未来的替代实现提供一份不依赖 rustc 代码的一致性基准，"借用规则的正确答案"首次可能脱离单一实现而存在。

6.4.2 对学习曲线与库 API 设计的意义

对最终用户，官方定位是 "Polonius Alpha solves the most-encountered borrow-check issues"[1-48]。具体而言（推断，标注）：URLO、Stack Overflow 与教学博客中反复出现的 E0502 误报类求助——get_or_insert、条件返回引用、分支间"传染性借用"——预计在稳定化后显著减少，"和借用检查器搏斗"叙事中最有据可查的一章将翻页[13-1]。但 entry API 不会因此过时：它对 &str key 仍需克隆、单次哈希仍优于"查两遍"，Polonius 消除的是"被迫改写"的挫败感而非最佳实践[50-1]。对库生态，意义更深远：burntsushi 当年的"红旗"（第 4 章，issue #92985）[53-2]正是 Alpha 拔除的对象，lending iterator 生态的前提由此具备[34-3]；而 view types、内部引用等更宏大的 API 演进，则如 6.3 节所示，仍悬挂在 Future 一栏。

稳定化路径清晰、形式化闭环正在成形、愿景分层明确、生态外溢已经开始——但一个被官方亲手留下的张力也浮出水面：一个被宣布"暂停 feature work"的项目，同时又是四个 Future 特性的地基。这一切说明了什么？第 7 章将给出回答。

7. 洞察：八年长路说明了什么

前六章还原了事实：公告（第 1 章）、NLL 前史（第 2 章）、诞生与困境（第 3 章）、Alpha 技术（第 4 章）、工程推进与验证（第 5 章）、未来路线（第 6 章）。本章除公告反响的时效性观察外不引入新事实，而是从已验证事实中提炼高阶判断；每条洞察均标注其前史出处，前瞻判断附置信度。

7.1 技术与治理洞察

7.1.1 同一思想四次表述、三次因可扩展性缩减

Polonius 的八年长路本质上不是一次技术失败，而是同一思想——流敏感的 outlives——的四次表述与三次缩减。第一次表述在 RFC 2094 内部：位置敏感的 outlives 约束 ('a: 'b) at P 本是 NLL 原设计，因"分析效率过低"在实现阶段被砍，这是一种解释（出自 ETH 博士论文的记载；该位置敏感 DFS 传播是否真正实现过仍有争议，rust#145029 至今开放，见第 2 章）[12-7][31-1]；第二次是 2018 年的 datalog Polonius，表达力一步到位，却被 origin²×point 的元组爆炸与急切不动点求解拖垮（第 3 章）[15-8]；第三次是 2023 年新公式化[7-6]的完整 location-sensitive 原型，2025 年 6 月 crates.io 压测暴露单函数 40 秒级耗时，不可 scale（第 5 章）[63-1]；第四次才是 Alpha——用"可达性近似 liveness + 沿用 NLL loans-in-scope"换掉对完整流敏感的执念，均值性能落入可稳定区间[55-6]。三次缩减的对象惊人一致：被砍的从不是方向，而是"完整物化流敏感信息"这一做法本身。由此看，Alpha 最合适的定位不是"新借用检查器"，而是 RFC 2094 愿景在 NLL 之后的又一次部分兑现——AST borrowck 无控制流概念；NLL 兑现了流敏感 liveness；Alpha 兑现了流敏感 outlives；kill 与完整路径敏感仍悬置（第 4 章表 4-1）。这一"先求理论上限、再逐级裁剪到可交付"的模式，已被官方制度化为 2026 项目目标的设计公理 "Don't let perfect be the enemy of good"[11-12]。【置信度：四次表述与后两次缩减为高；第一次缩减的原因为一种解释，置信度中】

7.1.2 Alpha 的"够用"边界由工程可行性划定，恰与高频痛点重合

Alpha 砍留之间的边界由工程可行性划定（见 4.2、5.1.3：完整流敏感无法 scale，遂改用可达性近似），而这条边界恰与社区高频痛点重合——并非由需求频率数据测量得出。被保留的 problem case #3 自 2016 年提出、曾反向塑造 entry API 设计（第 2 章）[12-8]；lending iterator filter（#92985）是 GAT 辩论中的"huge red flag"[34-4]；polonius-the-crab 等 workaround 的流行可视作需求热度的旁证（并无定量频率数据）[50-2]。被砍掉的链表条件 reborrow 需在图遍历内建模 kill，官方称剩余情形遇到的频率低得多，但未给出频率数据。官方原话 "solves the most-encountered borrow-check issues" 精确描述了这条分界[1-49]。同样值得注意的是公告的克制反应：HN 主帖 33 分仅 1 条评论[88]、Lobsters 0 评论[89]，而公告前一周一则转发视频在 daily.dev 上有 23 万次曝光（是曝光而非观看；视频是否起到预热作用为推断）[90]——与 2018 年 NLL 落地时的剧烈讨论形成对照。四期项目目标、贯穿两年的逐月月报把预期摊平，公告可能"只确认预期"（推断）；配合 MCP #1015"保持 nightly 开启直到稳定化"的长坡策略，稳定化暴露黑天鹅问题的概率被前置压缩[3-11]。低热度或可读作渐进式治理的成功信号而非冷淡（推断）。【置信度：中，推测——边界由工程可行性划定、与痛点重合为较可靠部分，热度解读为推断；热度观察时效性强，公告刊发仅一日，且 Reddit 因调研期访问受限未纳入渠道样本】

7.1.3 形式化、人力与"互不包含"的三重启示

第一重：形式化与实现是互相成就的关系。2023 年新公式化的洞见直接诞生于在 a-mir-formality 中重写借用检查的尝试——"modeling work is what gave us the insights"（第 3 章）[30-3]；反过来，Polonius 的目标是成为第一个行为被写入 Rust Reference 的借用检查器（upstream 尚未完成），以改变 Rust 长期无正式规范的状态，并为 gccrs 等替代实现提供一致性基准（第 6 章）[11-13]。第二重（推测）：公开记录里的关键人物很少——lqd 为连续 owner，Amanda Stjerna、Niko 参与设计与研究——项目节奏或许与他们的可用带宽有关；但这一点并无官方出处，且第 3 章显示 2019–2022 的冻结与 datalog 路线的性能死路及"先完备性后性能"的决策直接相关，人力至多是辅助解释。有官方自述支撑的只有一点：2026 年"Alpha 稳定后暂停 feature work"[1-50]与 lqd 自述时间减少、团队转向其他高优工作相互对应（第 5 章）[57-9]；lqd 2024 年获 Rust Foundation Fellowship[65-2]，但那发生在 2023 年重启之后，不能解释重启。第三重：Alpha 与 legacy 的接受集"互不包含"（各有对方不能编译的程序，第 4 章）揭示了软件考古学的罕见现象——官方只确认存在"Alpha 能过而 legacy 不能"的程序[1-51]，原因未说明；据底稿推测（置信度中），根因更可能是维护状态而非理论能力：legacy 空有完整流敏感，其 fact 生成或已与演化中的编译器前端脱节。其现实推论是：2026 年后 "Polonius" 一词应默认指树内 Alpha；引用 Polonius Book 或旧博客的能力描述时必须注明那已非现行实现。【置信度：第一、三重中（第三重为推测）；第二重低，推测】

7.2 前瞻

7.2.1 preview 期唯一未回答的变量与 Full Polonius 的人力前提

判断一【置信度：中】：2026 年底稳定化是可信承诺——拟稳定化子集已无已知 soundness 问题[1-52]、均值回归（+1.4%，来自 20,000 crate 的 tracking issue 月报[59-8]；官方博客的 top 10K 口径为显著回归很少、最差 +21%[1-53]）远低于 10–20% 预算、退出通道可逆（第 1、5 章）。preview 期唯一尚未回答的变量，是官方测量中 top 1 万之外借用密集 crate 的 2–3 倍回归在真实生态中是否频发——这正是公告三重目的之首，也是数月监控窗口真正要买的答案。若频发，后果更可能是拖慢（滑入 1.102，见第 6 章版本推测）而非阻断。判断二【置信度：事实部分高；"下一轮期货"为中，推测】：Full Polonius 在官方 roadmap 上标注 "Future" 且无负责人，官方已明示 Alpha 稳定后暂停 feature work、团队转向 next-gen trait solver 等旗舰任务[1-54][82-1]（以上事实部分置信度高）；（推测）人力或许是制约因素，其下一轮推进可能需要新的投入者出现，短期内社区不应期待时间表，"完整 Polonius"很可能成为下一轮社区期货（此表述为修辞性预测，置信度：中，推测）。判断三【推测】：若历史重演，Full Polonius 即便到来，也将以 Alpha 示范过的同样渐进方式落地——先求表达力上限，再裁剪到可交付，用治理摊平预期。这，或许就是八年长路留给 Rust 乃至所有生产语言编译器演进的方法论本身。

来源清单

1. Rust Blog, Jack Huey, Enabling the next iteration of the borrow checker on nightly — 2026-08-04. https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-nightly/↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

2. rust-lang/rust issue #160456, Tracking Issue: Polonius Alpha on nightly — 2026-08-03. https://github.com/rust-lang/rust/issues/160456↩︎↩︎↩︎

3. rust-lang/compiler-team MCP #1015, Enable -Zpolonius=next on nightly — 2026-07. https://github.com/rust-lang/compiler-team/issues/1015↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

4. rust-lang/rust PR #159343, Enable polonius alpha on nightly — 2026-08. https://github.com/rust-lang/rust/pull/159343↩︎↩︎

5. rust-lang/rust issue #153215, free region visitor for liveness marking regions dead and polonius alpha soundness — 2026-02-28. https://github.com/rust-lang/rust/issues/153215↩︎↩︎↩︎

6. rust-lang/rust PR #156027, Consider captured regions for opaque type region liveness — 2026-07-10 合入. https://github.com/rust-lang/rust/pull/156027↩︎↩︎↩︎↩︎

7. Inside Rust Blog, Polonius update — 2023-10-06. https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html↩︎↩︎↩︎↩︎↩︎↩︎↩︎

8. Rust Project Goals 2024h2, Scalable Polonius support on nightly — 2024-08. https://rust-lang.github.io/rust-project-goals/2024h2/Polonius.html↩︎↩︎↩︎

9. Rust Project Goals 2025h1, Scalable Polonius support on nightly — 2025-02. https://rust-lang.github.io/rust-project-goals/2025h1/Polonius.html↩︎↩︎↩︎

10. Rust Project Goals 2025h2, Stabilizable Polonius support on nightly — 2025-09. https://rust-lang.github.io/rust-project-goals/2025h2/polonius.html↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

11. Rust Project Goals 2026, Stabilize and model Polonius Alpha — 2026. https://rust-lang.github.io/rust-project-goals/2026/polonius.html↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

12. RFC 2094, Non-lexical lifetimes — 2017-08 开启. https://rust-lang.github.io/rfcs/2094-nll.html↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

13. Rust Users Forum, Yet another fight with the borrow checker — 2025-07. https://users.rust-lang.org/t/yet-another-fight-with-the-borrow-checker/131372↩︎↩︎

14. rust-lang/rfcs PR #2094 页面（含 "Remove migrate borrowck mode" 稳定化 PR 历史列表）, Non-lexical lifetimes — 2022. https://github.com/rust-lang/rfcs/pull/2094↩︎↩︎↩︎

15. Niko Matsakis, An alias-based formulation of the borrow checker, baby steps — 2018-04-27. https://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based-formulation-of-the-borrow-checker/↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

16. Rust Compiler Development Guide, The borrow checker — 访问 2026-08. https://rustc-dev-guide.rust-lang.org/borrow-check.html↩︎

17. Niko Matsakis, Non-lexical lifetimes based on liveness, baby steps — 2016-05-04. https://smallcultfollowing.com/babysteps/blog/2016/05/04/non-lexical-lifetimes-based-on-liveness/↩︎↩︎

18. rust-lang/rfcs, RFC 1211: MIR — 2015-07-14. https://github.com/rust-lang/rfcs/blob/master/text/1211-mir.md↩︎

19. Rust Blog, Announcing Rust 1.31 and Rust 2018 — 2018-12-06. https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018/↩︎↩︎

20. Felix Klock (pnkfx.org), Breaking News: Non-Lexical Lifetimes arrives for everyone — 2019-06-26. http://blog.pnkfx.org/blog/2019/06/26/breaking-news-non-lexical-lifetimes-arrives-for-everyone/↩︎↩︎

21. Niko Matsakis, Non-lexical lifetimes: introduction, baby steps — 2016-04-27. https://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/↩︎↩︎↩︎

22. Niko Matsakis, Non-lexical lifetimes: adding the outlives relation, baby steps — 2016-05-09. https://smallcultfollowing.com/babysteps/blog/2016/05/09/non-lexical-lifetimes-adding-the-outlives-relation/↩︎

23. Niko Matsakis, Non-lexical lifetimes using liveness and location, baby steps — 2017-02-21. https://smallcultfollowing.com/babysteps/blog/2017/02/21/non-lexical-lifetimes-using-liveness-and-location/↩︎

24. rust-lang/rust issue #44928, Tracking issue for RFC #2094: non-lexical lifetimes — 2017-09-29. https://github.com/rust-lang/rust/issues/44928↩︎

25. Rust Blog, Announcing Rust 1.36.0 — 2019-07-04. https://blog.rust-lang.org/2019/07/04/Rust-1.36.0/↩︎↩︎

26. Rust Blog, Completing the transition to the new borrow checker — 2019-11-01. https://blog.rust-lang.org/2019/11/01/nll-hard-errors/↩︎↩︎

27. Rust Blog（Niko Matsakis）, Non-lexical lifetimes (NLL) fully stable — 2022-08-05. https://blog.rust-lang.org/2022/08/05/nll-by-default/↩︎↩︎↩︎↩︎

28. Rust Blog, Announcing Rust 1.63.0 — 2022-08-11. https://blog.rust-lang.org/2022/08/11/Rust-1.63.0/↩︎

29. Rust Compiler Development Guide, Constraint propagation — 访问 2026-08. https://rustc-dev-guide.rust-lang.org/borrow-check/region-inference/constraint-propagation.html↩︎↩︎

30. Niko Matsakis, Polonius revisited, part 1, baby steps — 2023-09-22. https://smallcultfollowing.com/babysteps/blog/2023/09/22/polonius-part-1/↩︎↩︎↩︎↩︎

31. Vytautas Astrauskas 博士论文（§9.1.2）, Leveraging Uniqueness for Modular Verification of Heap-Manipulating Programs, ETH Zurich — 2024. https://pm.inf.ethz.ch/publications/Astrauskas2024.pdf↩︎↩︎

32. Niko Matsakis, Rust Belt Rust 2019 Sessions（"Polonius: Either Borrower or Lender Be, but Responsibly" 演讲摘要） — 2019-10-19. https://rust-belt-rust.com/sessions↩︎

33. rust-lang/rust issue #145029, Investigation: Did RFC 2094-NLL's DFS propagation for outlives in region infer algorithm ever get implemented in rustc? — 2025-08-07，开放中. https://github.com/rust-lang/rust/issues/145029↩︎

34. rust-lang/rust issue #92985, Filter adapter for LendingIterator requires Polonius — 2022-01. https://github.com/rust-lang/rust/issues/92985↩︎↩︎↩︎↩︎↩︎

35. rust-lang/polonius 仓库 README（含 "Why the name 'Polonius'?" 与算法变体说明） — 访问 2026-08. https://github.com/rust-lang/polonius↩︎↩︎↩︎

36. GitHub API: rust-lang/polonius 仓库元数据（created_at: 2018-05-01T15:40:59Z） — 访问 2026-08. https://api.github.com/repos/rust-lang/polonius↩︎

37. Niko Matsakis, Rust Belt Rust 2019 演讲幻灯片 Polonius – Where did you get that name? — 2019-10-19. https://nikomatsakis.github.io/rust-belt-rust-2019/↩︎

38. Frank McSherry, A relatively simple Datalog engine in Rust（含 2018-05-21 Treefrog Leapjoin 附言） — 2018-05-19. https://github.com/frankmcsherry/blog/blob/master/posts/2018-05-19.md↩︎↩︎↩︎

39. rust-lang/datafrog 仓库 README（Authorship 说明） — 访问 2026-08. https://github.com/rust-lang/datafrog↩︎

40. Albin (Amanda) Stjerna, Modelling Rust's Reference Ownership Analysis Declaratively in Datalog，Uppsala University 硕士论文 — 2020；修订版 2021-06-09. https://www.diva-portal.org/smash/get/diva2:1684081/fulltext01.pdf↩︎↩︎↩︎↩︎↩︎↩︎

41. Inside Rust Blog, 2019-11-14 Compiler Team Triage Meeting（wg-polonius 同步记录） — 2019-11-19. https://blog.rust-lang.org/inside-rust/2019/11/19/compiler-team-meeting/↩︎↩︎

42. The Polonius Book, Current status and roadmap 与 Loan analysis — 访问 2026-08. https://rust-lang.github.io/polonius/current_status.html↩︎↩︎

43. rust-lang/polonius RELEASES.md（v0.6.0–v0.7.0 优化编年） — 访问 2026-08. https://github.com/rust-lang/polonius/blob/master/RELEASES.md↩︎

44. rust-lang/polonius PR #179 Add an optional Soufflé backend、PR #183 Rewrite polonius-engine — 2021-08 / 2022-01. https://github.com/rust-lang/polonius/pull/179 ; https://github.com/rust-lang/polonius/pull/183↩︎↩︎

45. rust-lang/rust issue #75858, Polonius performance problem on nix and libc — 2020-08. https://github.com/rust-lang/rust/issues/75858↩︎

46. rust-lang/rust issue #138102 / rust-lang/polonius issue #199, Extremely slow while compiling pulldown-cmark with -Zpolonius — 2025-03. https://github.com/rust-lang/rust/issues/138102↩︎

47. rust-lang/polonius releases（polonius-engine v0.13.0，2021-08-03） — 访问 2026-08. https://github.com/rust-lang/polonius/releases↩︎

48. rustc nightly 文档 rustc_session::config::Polonius（Off/Legacy/Next 枚举） — 访问 2026-08. https://doc.rust-lang.org/stable/nightly-rustc/rustc_session/config/enum.Polonius.html↩︎↩︎

49. rust-lang/rust issue #54663, Borrow checker extends borrow range in code with early return — 2018-09-29. https://github.com/rust-lang/rust/issues/54663↩︎

50. polonius-the-crab crate README — 访问 2026-08. https://lib.rs/crates/polonius-the-crab↩︎↩︎↩︎

51. Hacker News, In Defense of Polonius（JSTOR Daily 莎剧人物文章讨论帖；最高赞评论："Dang. I had hoped this was about the new borrow checker in Rust."） — 2022-06-17. https://news.ycombinator.com/item?id=31781946↩︎

52. Niko Matsakis, Polonius revisited, part 2, baby steps — 2023-09-29. https://smallcultfollowing.com/babysteps/blog/2023/09/29/polonius-part-2/↩︎↩︎↩︎

53. Generic Associated Types Initiative, Concern: GATs are too hard to learn / too rough to stabilize（含 burntsushi "huge red flag" 引文） — 2022. https://rust-lang.github.io/generic-associated-types-initiative/mvp/concern-too-rough.html↩︎↩︎↩︎

54. nightly rustc 源码文档 rustc_borrowck::polonius — 访问 2026-08. https://doc.rust-lang.org/stable/nightly-rustc/rustc_borrowck/polonius/index.html↩︎↩︎↩︎↩︎

55. rust-lang/rust PR #143093, Simplify polonius location-sensitive analysis — 2025-08-10 合并. https://github.com/rust-lang/rust/pull/143093↩︎↩︎↩︎↩︎↩︎↩︎↩︎

56. rust-lang/rust PR #123720, Rewrite handling of universe-leaking placeholder regions into outlives constraints — 2024. https://github.com/rust-lang/rust/pull/123720↩︎

57. Rust Blog, Project goals update — April 2026 (end of 2025H2) — 2026-05-18. https://blog.rust-lang.org/2026/05/18/project-goals-2026-04/↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

58. rust-lang/rust PR #136299, Ignore NLL boring locals in polonius diagnostics — 2025. https://github.com/rust-lang/rust/pull/136299↩︎↩︎

59. rust-project-goals tracking issue #118 及全部月度评论（2024-07-22 创建，lqd/nikomatsakis/tomassedovic） — 2024-07–2026-07. https://github.com/rust-lang/rust-project-goals/issues/118↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

60. rust-lang/rust PR #134268, Foundations of location-sensitive polonius — 2024-12-22 合入. https://github.com/rust-lang/rust/pull/134268↩︎

61. rust-lang/rust PR #149639, inline constant localized typeck constraint computation — 2026-01-23 合入. https://github.com/rust-lang/rust/pull/149639↩︎

62. rust-lang/rust PR #150551, Compute localized outlives constraints lazily — 2026-02-13 合入. https://github.com/rust-lang/rust/pull/150551↩︎↩︎

63. Rust Blog, Project goals update — July 2025（lqd 2025-06-30 期末评论） — 2025-08-05. https://blog.rust-lang.org/2025/08/05/july-project-goals-update/↩︎↩︎

64. Rust Blog, Project goals for 2025H2（RFC #3849 旗舰主题公告） — 2025-10-28. https://blog.rust-lang.org/2025/10/28/project-goals-2025h2/↩︎

65. Rust Foundation, Announcing the Rust Foundation's 2024 Fellows（Rémy Rakic 条目） — 2024-10-14. https://rustfoundation.org/media/announcing-the-rust-foundations-2024-fellows/↩︎↩︎↩︎

66. EuroRust 2024, Amanda Stjerna, The first six years in the development of Polonius — 2024-10. https://eurorust.eu/2024/talks/the-first-six-years-in-the-development-of-polonius/↩︎

67. rust-lang/rust PR #130227, Remove precise placeholder tracking from region inference — 2026-01-22 未合并关闭. https://github.com/rust-lang/rust/pull/130227↩︎

68. rustc-dev-guide, UI tests — Compare modes — 2026-08 检索. https://rustc-dev-guide.rust-lang.org/tests/ui.html↩︎

69. rust-lang/compiler-team MCP #996, Test new solver and polonius alpha on CI — 2026. https://github.com/rust-lang/compiler-team/issues/996↩︎

70. rust-lang/rust tests/ui/nll/polonius/ 目录 — 2026-08 检索. https://github.com/rust-lang/rust/tree/master/tests/ui/nll/polonius↩︎

71. rust-project-goals issue #122, Expanding a-mir-formality… — 2025-12 起. https://github.com/rust-lang/rust-project-goals/issues/122↩︎

72. rustc-dev-guide, Stabilizing language features — 访问 2026-08. https://rustc-dev-guide.rust-lang.org/stabilization_guide.html↩︎

73. Rust Forge, Current Release Versions — 访问 2026-08. https://forge.rust-lang.org/↩︎

74. Rust Project Goals 2025H2, Borrow checking in a-mir-formality — 2025. https://rust-lang.github.io/rust-project-goals/2025h2/a-mir-formality.html↩︎

75. Rust Blog, Project goals update — December 2025（Niko Matsakis 关于 a-mir-formality PR #206/#207/#210 的评论） — 2026-01-05. https://blog.rust-lang.org/2026/01/05/project-goals-2025-december-update/↩︎

76. Rust Project Goals 2026, Experimental language specification — 2026. https://rust-lang.github.io/rust-project-goals/2026/experimental-language-specification.html↩︎

77. Rust Project Goals 2026, Expanding a-mir-formality to work better as a Rust type system spec — 2026. https://rust-lang.github.io/rust-project-goals/2026/a-mir-formality.html↩︎

78. rust-lang/lang-team #179, Meeting proposal: Rust Specification — 2022. https://github.com/rust-lang/lang-team/issues/179↩︎

79. Jung, Jourdan, Krebbers, Dreyer, RustBelt: Securing the Foundations of the Rust Programming Language（POPL 2018）及 Ralf Jung Research Statement — 2018. https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf↩︎

80. Weiss, Patterson, Matsakis, Ahmed, Oxide: The Essence of Rust — 2019/2021. https://arxiv.org/abs/1903.00982↩︎

81. Wu, J. et al., RustCompCert: A Verified and Verifying Compiler for a Sequential Subset of Rust — 2026-02. https://arxiv.org/abs/2602.07455↩︎

82. Rust Project Goals 2026 Roadmaps, The Borrow Checker Within — 2026. https://rust-lang.github.io/rust-project-goals/2026/roadmap-borrow-checker-within.html↩︎↩︎

83. Niko Matsakis, The borrow checker within, baby steps — 2024-06-02. https://smallcultfollowing.com/babysteps/blog/2024/06/02/the-borrow-checker-within/↩︎

84. rust-lang/rust-project-goals #113, Stabilize the next-generation trait solver — 2026. https://github.com/rust-lang/rust-project-goals/issues/113↩︎

85. danielhenrymantilla/polonius-the-crab.rs 仓库 — 访问 2026-08. https://github.com/danielhenrymantilla/polonius-the-crab.rs↩︎

86. Rust Blog, gccrs: An alternative compiler for Rust — 2024-11-07. https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust/↩︎

87. Phoronix, Big Rust Update Merged For GCC 15 - Lands The Polonius Borrow Checker — 2025-03-17. https://www.phoronix.com/news/GCC-15-Big-GCCRS-Update↩︎

88. Hacker News 公告主帖（item 49169842） — 2026-08-05 抓取. https://news.ycombinator.com/item?id=49169842↩︎

89. Lobsters, Enabling Polonius Alpha on nightly 讨论页快照 — 2026-08-05 抓取. https://lobste.rs/s/gkflvn/enabling_polonius_alpha_on_nightly↩︎

90. Let's Get Rusty, *Rust's new borrow checker is coming!*（daily.dev 转发视频，230.4K 曝光，非观看数） — 2026-07-28 发布. https://daily.dev/posts/rust-s-new-borrow-checker-is-coming--llpxltaj6↩︎