ty：Astral 出品的极速 Python 类型检查器
阅读时间: 大约 8 分钟
ty：Astral 出品的极速 Python 类型检查器
2025 年 12 月 16 日，打造了 Python 包管理器 uv 与 linter Ruff 的 Astral 团队发布了 ty 的 Beta 版本：一个用 Rust 编写、面向 Python 的极速类型检查器与语言服务器（LSP），定位是 mypy、Pyright、Pylance 的替代者。Astral 在公告中明确表示，自家项目已经”完全只使用 ty”，并准备向”有追求的用户”推荐其用于生产。本文基于官方公告与公开基准数据，客观分析它的机制、性能与边界。
一、为什么是它：Python 类型检查的性能债
Python 的渐进式类型（gradual typing）生态长期面临一个尴尬的现实：mypy 作为事实标准，在大型代码库上慢得令人难以忍受；微软的 Pyright/Pylance 用 TypeScript 重写了一遍，速度明显更快，但仍以”单次全量检查”为主要交互模式。随着代码库膨胀到数十万行、编辑器需要实时反馈，类型检查从”CI 里跑一次”变成了”每次按键都要响应”，单次运行的绝对速度已经不够，增量重算的速度才决定体验。
Astral 的切入点很清晰：用 Rust 重写，并把整个架构围绕”增量性”（incrementality）设计——只在文件或函数被修改时，重跑必要的计算，而不是全量重检。
二、它是什么：一个类型检查器 + 一个 LSP
ty 同时是两件事：
- 命令行类型检查器：可以在 CI 或本地一次性扫描整个项目，对标 mypy / Pyright CLI；
- 语言服务器：原生为编辑器而生，支持 Go to Definition、Symbol Rename、Auto-Complete、Auto-Import、Semantic Syntax Highlighting、Inlay Hints 等现代 LSP 能力，可在 VS Code、Cursor 等任何实现 LSP 的编辑器中运行。
安装方式为 uv tool install ty@latest，或直接装 VS Code 扩展。代码以 MIT 协议开源，官方称连编辑器扩展也是开源的，且可以在浏览器里运行。
三、性能机制：增量架构是关键
ty 的性能优势来自两个层面。
第一是实现语言：Rust 带来的单线程吞吐优势。官方称，在不使用缓存的情况下，ty 比 mypy 和 Pyright 稳定快 10 到 60 倍。
第二是增量架构（这才是与同类 Rust 工具拉开数量级差距的地方）。官方给出的两个场景很能说明问题：
| 场景（官方机器 M4，无缓存） | ty | Pyright | Pyrefly | mypy |
|---|---|---|---|---|
| home-assistant 项目命令行全量检查 | 2.19s | 19.62s | 5.32s | 45.66s |
| PyTorch 项目中编辑一个核心文件后 LSP 重算诊断 | 4.5ms | 370.5ms | 2.60s | — |
第二行的差距尤其夸张：在 PyTorch 这种巨型仓库里改一个”承重文件”后，ty 重算诊断只要 4.5ms，而 Pyright 需要 370.5ms、Pyrefly 需要 2.60s——官方正文里的表述是”比 Pyright 快 80 倍、比 Pyrefly 快 500 倍”。
需要特别指出的是口径问题：这些数字全部来自 Astral 官方在单台 M4 机器上、针对单个开源项目、无缓存条件下的自测，并非第三方独立复现的基准。公告正文里写的是 4.7ms / 386ms / 2.38s，而配图里标注的是 4.5ms / 370.5ms / 2.60s——同一篇文章内部两组数字就存在小幅出入，说明这是示意性自测值，不应被当作严谨的 bench 结论引用。
四、正确性：不只是更快
Astral 反复强调：“我们的目标不只是做一个更快的类型检查器，而是做一个更好的。“ty 在类型系统上推进了几项能力：
- 一等公民的交叉类型（intersection types）；
- 更高级的类型收窄（type narrowing）；
- 成熟的可达性分析（reachability analysis），用于区分”代码真的走不到”和”类型上走不到”。
其诊断系统（diagnostic）刻意对标 Rust 编译器的报错体验：一条诊断可以同时从多个文件拉取上下文，既告诉你”哪里错了”，也解释”为什么错”以及”通常怎么修”——例如给 TypedDict 键赋了错误类型时，ty 会同时标出赋值处的类型不匹配和对应的条目声明。官方称这套诊断从一开始就同时为”人和 agent”设计。
五、优势与局限（含 Beta 边界）
优势：
- 性能代差明显：全量检查比 mypy 快一个数量级以上，增量重算相对 Pyright/Pyrefly 更是数量级优势，这对大型仓库的实时编辑体验是质变；
- 工程一致性：与 uv、Ruff 同属一套工具链，未来可串联出死代码消除、未用依赖检测、SemVer 升级校验、CVE 可达性分析、类型感知 lint 等语义能力；
- 开源开放：MIT 协议、开放贡献、可在浏览器运行。
局限与口径偏差（官方自己承认的部分）：
- 仍是 Beta：官方把 Beta 到 Stable 之间的工作明确列为三件事——(1) 稳定性与 bug 修复；(2) 补完 Python typing 规范的”长尾”特性；(3) 对 Pydantic、Django 等主流第三方库的一等支持。这意味着今天的 ty 在类型规范覆盖和复杂第三方库兼容上还没有达到 mypy/Pyright 的成熟度；
- 基准是自测口径：如上所述，所有速度数字来自官方单机器单项目，缺少独立复现，实际项目中的加速比需要自行验证；
- 正确性未经长期检验：能否在”少误报”上真正超过 mypy，官方给出了 first-class intersection types 等设计方向，但没有提供与 mypy 的错误率对比数据。
六、谁该关注
- 大型 Python 仓库的维护者：被 mypy 慢、被 Pyright 增量体验困扰的团队，可以优先在非关键路径试用；
- 追求编辑器实时反馈的开发者：4.5ms 级别的增量重算对”边写边查”体验提升显著；
- Pydantic / Django 重度用户：建议先观望到 Stable——官方明确把这两个库的一等支持列为 Beta 之后的工作。