如果你在大型 Python 代码库里维护过类型检查,大概体会过那种痛苦:一次全量检查跑几分钟,增量检查也慢得让人想砸键盘,CI 排队时间越来越长,开发体验被拖垮。Google 内部也一直被这个问题困扰,他们自研的 Pytype 用了十几年,但最近终于忍不了了——直接换成了 Meta 开源的 Pyrefly。这个决定不是拍脑袋,Google 给出的数据相当惊人:Pyrefly 比 Pytype 快约 10 倍,增量重建延迟最高降低 98%,类型检查的峰值计算成本削减超过 80%,干净构建关键路径上的类型检查时间减少了 90% 到 99%,Google 原话是"消除了一个长期存在的开发瓶颈"。

为什么 Pytype 会落后这么多?根源在于它的实现思路。Pytype 不是直接分析 Python 源码的抽象语法树(AST,就是代码被解析成树状结构后的表示),而是去分析编译后的字节码(Python 代码先编译成的中间指令序列)。早期这么做有它的道理,但随着 Python 类型系统快速演进,问题来了:字节码在不同 Python 版本之间不稳定,每次 Python 发新版本,Pytype 都要跟着适配,维护成本越来越高,跟上新的类型 PEP(Python 增强提案,即 Python 社区提出的新特性或规范)也越来越吃力。这就像你为了修一栋老房子,每次都得先拆墙,而 Pyrefly 直接看图纸,省事得多。

Pyrefly 的另一个核心优势是对 Python 类型规范的遵循度极高。Google 提到,Pyrefly 在类型规范一致性测试套件中通过了约 97% 的测试,这意味着它检查出来的类型错误更接近 Python 官方定义的标准,误报和漏报都更少。而且 Pyrefly 是社区活跃维护的项目,能更快跟上新语法。它的诊断信息也更实用,会在代码里直接给出内联标注,指出错误的根本原因,有些情况甚至直接给出修复建议,而不是像老式检查器那样只丢给你一行晦涩的报错。

Accelerating Performance by Incrementally Integrating Rust into Existing Codebas
Accelerating Performance by Incrementally Integrating Rust into Existing Codebas

这里值得展开说一下 Pyrefly 的性能来源。它用 Rust 实现,Meta 去年开源时给出的数据是每秒能检查 180 万行代码,这个速度让"每次按键都做类型检查"成为可能。Rust 的性能优势加上对源码 AST 的直接分析,让 Pyrefly 在冷启动和增量检查上都远胜 Pytype。Google 的基准测试也印证了这一点,Pyrefly 大约比 Pytype 快 10 倍,增量重建延迟降低 98%,峰值计算成本降低 80% 以上。

Evolutionary Architecture in Practice
Evolutionary Architecture in Practice

社区对 Google 这个决定的反应也挺有意思。大部分人都认同 Pytype 确实不如 Pyrefly,但争论的焦点转向了 Pyrefly 和另外两个主流检查器 Ty、Mypy 的对比。有开发者指出 Pyrefly 已经过了 1.0 版本,比 Ty 成熟得多,性能接近但更经过实战检验。也有人为 Mypy 辩护,说它在大型项目上的增量检查依然很快,但立刻有人反驳说 Mypy 2.0 在大型项目冷检查上号称快 5 倍,但新一代检查器比它还要快一个数量级。

What 25 Trillion Tokens Reveal About How Developers Actually Adopt AI Agents
What 25 Trillion Tokens Reveal About How Developers Actually Adopt AI Agents

一位 Python 开发者 Amirrea Azadmher 在 LinkedIn 上的评论提供了一个更务实的视角:类型检查器的价值不只是省 CI 里的 30 秒,更重要的是它如何改善开发过程中的编辑-检查循环——就是你写代码、保存、看报错、改代码这个反复迭代的过程。他建议不要轻信别人 monorepo(单一代码仓库,即把多个项目放在一个仓库里管理)的基准数据,要在自己的代码树上实测冷启动和热启动时间,同时把诊断质量和吞吐量一起评估——一个检查得飞快但报错全是噪音的工具,实际成本可能比一个慢一点但能精准指出问题所在的工具更高。

The Minimum Viable Manager: Building Trust, Feedback, and Alignment
The Minimum Viable Manager: Building Trust, Feedback, and Alignment

这个观点其实点出了选型的关键:类型检查器的速度固然重要,但诊断质量同样关键。Pyrefly 在这两方面都做得不错,这也是 Google 愿意替换掉自研工具的原因。对于普通开发者来说,这个案例的启发是:当你的工具链成为瓶颈时,不要因为"用习惯了"或"是自研的"就死守不放,开源生态里可能有更好的替代品。具体到 Python 类型检查这个场景,如果你还在用老旧的检查器,或者项目规模大到检查速度已经影响开发效率,Pyrefly 值得一试。

Exploding GPUs
Exploding GPUs

当然,换工具也有成本。Pyrefly 的配置、与现有 CI 的集成、团队的学习曲线都需要考虑。但考虑到 Google 这种体量的公司都愿意为此付出迁移成本,说明收益是实打实的。如果你正在评估 Pyright、Pyrefly 和 Mypy,最好的做法就是像那位开发者建议的:在自己的代码树上跑一遍基准测试,看看冷启动和增量检查的实际耗时,再对比一下诊断质量,别被别人的数字带着走。

最后提一句,Pyrefly 是 Meta 开源的,这意味着它背后有大厂持续投入,社区也在活跃迭代。对于 Python 类型检查这个领域来说,多一个强劲的竞争者,最终受益的是所有 Python 开发者。

阅读原文 → 返回 AI 技术文档

内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/google-pyrefly-python/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global