Mypy 跑了这么多年，大家其实都习惯了它的速度——或者说，习惯了它的慢。
Meta 的工程师们显然没打算继续忍。他们掏出了 Pyrefly，一个完全用 Rust 重写的 Python 类型检查器和语言服务器，目前 6.3K stars，13234 次提交，社区活跃度看起来不低。
为什么是 Rust
这不是什么新鲜思路了。Ruff 用 Rust 重写 linter 之后速度快了一个数量级，UV 接管了 Python 包管理，现在类型检查器也走上了同一条路。
Pyrefly 的核心卖点很直接：快。用 Rust 意味着没有 Python 解释器本身的开销，类型推断和检查逻辑可以直接编译到机器码级别。对于大型代码库来说，每次运行 mypy 要等几十秒的体验确实折磨人。
Meta 内部有庞大的 Python 代码库，他们不是闲得无聊才做这个。Instagram 的服务器端大量使用 Python，类型检查慢一分钟，CI 流水线就慢一分钟，几百个工程师一天浪费的时间加起来不是小数目。
和现有工具比怎么样
目前 Pyrefly 对标的是 mypy 和 pyright 这两个主流选项。
mypy 是 Python 类型检查的事实标准，生态最成熟，但速度一直是个痛点。pyright 是微软做的，基于 TypeScript/JavaScript，对 VS Code 集成最好，速度比 mypy 快，但也不是快到飞起的那种。
Pyrefly 的 README 没有给出具体的 benchmark 数字——这点挺遗憾的。按 Rust 重写项目的惯例，速度提升应该在 5-50 倍之间，具体取决于代码库规模和类型复杂度。
我的判断是：别急着迁移。 Pyrefly 还处于积极开发阶段，issue 区有 459 个未解决问题，PR 队列 128 个。这说明它在快速迭代，但也意味着稳定性和兼容性还没到生产级别。
能不能用
如果你在自己的项目里跑着 mypy，偶尔觉得慢，Pyrefly 还不足以让你现在就去替换。它的类型系统覆盖度和 mypy 比还有差距，特别是一些边缘 case——泛型、协议类型、类型守卫这些高级特性。
但如果你的团队规模大、代码库超过百万行、CI 里类型检查成了瓶颈，那值得持续关注。Meta 内部已经在用了，他们不会拿自己的生产环境开玩笑。
等 Pyrefly 到 1.0 版本、benchmark 数据出来、和 mypy 的兼容性测试跑完——那个时候再考虑迁移，更稳妥。
我目前的态度是：加个 watch，不急着装。 类型检查器不是玩具，换错了成本不低。
一个有意思的信号
Pyrefly 的 .llms/rules 目录下有 .llms/rules 文件，里面写着"Point more agentic tools to the AGENTS.md file"。这说明 Meta 在做这个工具的时候，已经把 AI 编程助手的使用场景考虑进去了。类型检查器不只是给人跑的，也是给 AI agent 跑的——agent 写代码之后需要即时反馈，等 30 秒和等 3 秒的区别，对 agent 来说比对人更大。
这个细节比速度数字更让我觉得 Pyrefly 值得跟。
主要来源：