从 Go 版 TS7 到 Rust 版 tsrs
10 月 20 号，Cloudflare 发布博客，介绍其与 VoidZero 合作完成的 tsrs 项目：把 TypeScript 7 编译器从 Go 移植到 Rust，并孵化在 Oxc 工具链中。此前，TypeScript 7（Go 原生编译器）已在 7 月初发布。tsrs 没有另起分支，而是对 Go 实现逐函数移植，兼容性文档直接写明“Go code is the spec”：诊断、诊断顺序、消息文本、退出码只要与 Go 版对不上，就算 tsrs 的 bug。
该项目带有上游同步机制。npm 包版本号包含上游提交信息，例如 0.18.0-ts7.1.0-dev.20260929，对应 microsoft/TypeScript@b85298b6a81f 的 7.1.0-dev 提交；仓库每晚运行 TypeScript 官方测试套件，生成兼容性矩阵。官方数据称，同配置下 tsrs 相比 TS 7.0 快至多 8 倍，并节省约 70% 内存。
报错能对齐，退出码差异值得 CI 检查
对类型检查器来说，比速度更优先的是兼容性。素材中的测试者在一台 1核2G 机器上准备了一个 199 个 .ts 文件、约一万多行的项目，并埋入 6 类错误，包括泛型推断失败后产生的连带错误。最终 tsc 与 tsrs 共输出 10 条诊断，错误码、文件行号、消息文本和打印顺序逐字符一致。
官方测试套件中，tsrs 对齐了 13,458 / 13,462 个错误基线，差 4 个。但退出码出现了一个工程细节：同一有错项目，tsc 7.0.2 返回 1，tsrs 返回 2，@tsrs/wasm 也返回 2；无错时两边均为 0。若 CI 只判断非零，影响不大；若脚本写死 -eq 1，或需要靠退出码区分错误类型，就需要重新验证。tsrs 的 wasm 文档还将 0 到 4 标为编译器常规状态，5 表示 wasm 层面的崩溃或内存不足。
性能不等于官方倍数，Wasm 是更明确的增量
在小项目与低配置环境下，实测性能没有达到官方 8 倍。由于进程冷启动占比较高，测试中的提升约为 1.8 到 2.2 倍。且测试口径并不完全相同：tsrs 跟踪 7.1.0-dev，对比的 tsc 为 7.0.2。官方 8 倍来自大型仓库与更高配置环境，不宜直接套用到中小项目。
Rust 带来的更直接变化是 Wasm。Go 编译 WebAssembly 需要带上 GC，Rust 不需要，因此 tsrs 可以进入浏览器和 Cloudflare Worker 沙箱等场景。@tsrs/wasm 已发布，支持 Node 22 以上和浏览器；测试中首次运行 1075 ms，第二次 417 ms，内存 110 MB，并可通过内存文件系统获得带 UTF-16 坐标的 JSON 诊断。当前 wasm 版为单线程，大仓库下与原生版会有差距。
现在是否接入，要看平台和流水线
tsrs 仍有明确限制。0.18.0 及之前只提供 macOS arm64 和 Linux x64/arm64（glibc/musl）二进制，Windows x64 尚未支持，Intel Mac 也没有。命令层面，--init、--showConfig 不支持，--locale 被忽略，--generateTrace 缺失；--watch 可在 Linux 和 macOS 上使用，官方称 39/42 个 watch 场景基线通过，Windows 上会报不支持。
版本也存在漂移风险。npm latest 目前指向 7.1.0-dev 移植，跟随上游 dev 分支，不同时间安装可能对应不同快照。对于需要稳定结果的 CI，这一点需要提前锁定版本。
- 适合先试：Linux/macOS CI、内存敏感的构建环境、浏览器内类型检查、Worker 沙箱场景。
- 建议等待：Windows 开发机为主，或强依赖特定退出码、诊断格式的老流水线。
tsrs 当前更像是一个把 TypeScript 类型检查带向浏览器与沙箱环境的工程选项。它把工具链竞争从单纯速度拉回兼容性、退出码、命令支持和版本稳定性。对团队来说，是否接入不取决于它是否用 Rust 重写，而取决于现有流水线能否消化这些细节差异。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/rust-ban-typescript-bian-yi-qi-tsrs-kai-shi-luo-di-zhen
