现在的 TypeScript 类型检查工具链出现了三个选项，各有各的位置。厘清它们的边界很重要。
微软的 Go 编译器（官方） TypeScript 7 的原生实现，是官方路线。命令行行为和语言服务是标准参照。
tsc-rs（Rust 移植） 第三方项目，目标是 drop-in 替换原生编译器、语言服务和编程接口。
声称在六个开源应用上比 Go 版快 1.61 倍（几何平均）。但这是维护者自己跑的，测试在 Apple M4 Pro 上，关闭增量编译，五次测量。
限制：只有 Linux x64 和 Apple Silicon 预构建包，编辑器功能（快速修复、重构、hover、补全）都没移植。版本钉在 9 月 29 日的 TypeScript 7.1 开发修订版。
Bun 的检查器 在同一组测试里整体最快。但仓库指出诊断信息有差异，而且 Bun 不提供集成的 Effect 检查。
为什么 Bun 最快但未必是你的选择 速度只是维度之一。诊断信息不一致意味着：同一个错误，Bun 给的提示可能和 tsc 不一样。对于依赖特定诊断信息做 CI 检查或者编辑器集成的项目，这个差异是实质问题。
tsc-rs 最需要注意的一点 维护者明确说代码是 LLM 生成的，两周完成，API 成本约 24000 美元，并且代码没有被逐行人工审读。
这不代表不能用，但它决定了定位——可测试的工程实验，不是已定型的替代方案。
选择决策树
- 生产项目、Windows 环境、需要完整编辑器功能：用官方 Go 编译器。没得选，其他两个都不满足。
- Linux 或 macOS、只想加速 CI 里的类型检查、不需要编辑器功能：可以评估 tsc-rs，但必须用自己的代码库跑对比。
- 已经用 Bun 做运行时和构建、对诊断差异不敏感：Bun 检查器是最快的。
评估 tsc-rs 的正确方法
- 不要替换现有 TypeScript 包，它有独立归档和 npm 包两种形式，可以并行安装。
- 对着它钉住的上游修订版比对诊断信息，别拿 TypeScript 7.0 或 native-preview 比。
- 跑你自己的构建负载，别把项目的兼容率当成对你代码库的保证。
一个提醒 编译速度很重要，但对于绝大多数项目，类型检查不是 CI 的主要瓶颈。测试、构建、部署往往占大头。
先测一遍你的 CI 时间分布，确认类型检查确实是瓶颈，再去折腾换编译器。否则优化了一个占比 10% 的环节，整体收益很有限。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。