不是新语言，也不是重学 TypeScript。代码照旧写，只是底下那个干活的编译器，从 tsc 换成了 Rust 版本。2026 年 10 月 20 日发布，官方口径是类型检查最快 8 倍、内存少约 70%。
这两天前端圈讨论挺多的一件事：Cloudflare 和 VoidZero 搞了个 tsrs，一个用 Rust 实现的 TypeScript 编译器。
先把结论放前面：它不是新语言，也不是让你重学 TypeScript。你原来怎么写 TS，还是怎么写。变的只是底下干活的那个编译器。
官方给出的数据挺猛：类型检查最高快 8 倍（对比 TypeScript 7.0），内存占用降了大约 70%。另外，开发过程中发现的一些优化已经回馈给上游，TypeScript 7.1 Beta 最高也有 2.5 倍提升。
不过这里得说清楚：70% 的内存下降来自官方基准测试，不等于 Wasm 版本已经拿到了同样的收益。看性能数字，还是得看清测试场景。
tsrs 到底是什么
简单说，tsrs 是在尽量兼容官方实现的前提下，用 Rust 重写 TypeScript 编译器的核心能力。
我们平时用的 tsc，主要干两件事：类型检查 ，以及把 TypeScript 编译成 JavaScript。tsrs 想做的就是把这些能力用 Rust 重新实现一遍，让类型检查更快、内存占用更低。
项目由 Cloudflare、VoidZero 和 Max Schwenk（来自 Owner.com）合作推进，目前放在 Oxc 工具链里孵化。
关键在于它不是 fork。官方博客里这句话写得很明确：
To be clear, we are not forking TypeScript.（说清楚：我们不是把 TypeScript 分叉出去。）
他们的理由是：TypeScript 团队对某些特性会花好几年反复试方案、做原型，才定下实现。Rust 移植必须紧跟这些决策，否则迟早散架、变得不兼容。所以语言的设计和方向，仍然只归 TypeScript 团队管。
这个态度我觉得挺关键------至少不是纯造轮子。
8 倍和 70%，该怎么读
这张图的三个前提，比数字本身重要：
**第一，对比基准是 TypeScript 7.0，也就是已经是 Go 重写过的版本。**不是拿十年前的 tsc 来比。也就是说，这 8 倍是在一个已经快了很多的起点上再拉出来的。
**第二，前提是「同样数量的 type-check worker」。**官方特意说明，他们和 TypeScript 团队一起确认过基准配置一致------因为之前市面上一些 TypeScript 移植版的跑分，是靠更大的机器规格和跟默认值不同的编译选项堆出来的。tsrs 默认还带一套「按机器规格自适应」的配置，比图表里这组更吃内存，但跑得更快。
第三，8 倍是「最高」，不是「平均」。 up to 这两个字，在任何编译器的宣传里都值得单独圈出来。
至于 70% 的内存下降，那是官方在原生环境下的基准结果。Wasm 版本（@tsrs/wasm）是另一套东西，内存收益能不能对齐，现在没有结论。
微软刚用 Go 重写，Rust 版又来干嘛
前段时间微软才用 Go 重写了 TypeScript 编译器，官方说法是比原来的 JS 实现快约 10 倍、内存也省得多。现在 Cloudflare 又推 Rust 版本，乍一看像编译器也要开始「语言大战」了。
但 Cloudflare 看中的不只是速度，更是 WebAssembly。
逻辑很硬：Go 编译到 Wasm，得把运行时和垃圾回收器一起带上；Rust 没有传统 GC，内存管理模型让 guest 和 host 之间的内存交互变得直接。这不是「谁更快」的问题，是「谁能更轻地塞进沙箱」的问题。
Cloudflare Workers 支持 Wasm 很久了，几周前还刚宣布支持 Workers 里直接跑原生 Rust（新的 wasm-bindgen Emscripten target）。把这些拼起来看，意图很清楚：让整套构建、检查、类型检查的流水线，能在 Workers 上以极小的内存占用跑起来。
放到 AI Agent 场景下就更清楚了。以后 Agent 可能要在轻量沙箱里反复做代码生成、类型检查、错误修复，而不是每次都拉起一整套传统开发环境。编译器如果足够轻，想象空间就大很多------浏览器里、嵌入式设备上、IoT 应用里，都能跑。
AI 已经开始参与重写编译器了
官方博客里还有个信息挺有意思：前沿 AI 模型已经能在几天内，几乎独立地完成大规模代码移植。
博客里提到，这些年把 TypeScript 移植到别的语言的尝试一直没断，但因为复杂度太高，真正成功的只有 TypeScript 团队自己那次从 JavaScript 到 Go 的移植。而现在，市面上已经出现了 slopforks、忠实移植版、乃至完全重写架构的 Rust / C++ 版本。
换句话说，过去重写这种复杂编译器得砸大量工程资源，现在 AI Agent 能承担相当一部分。
维护方式更值得关注。他们打算照搬 Cloudflare 维护 Vinext（对齐 Next.js）的那套流程：
每天早上一轮 Agent 检查上游变更、拉 diff、为可能影响移植的改动开 issue；每天晚上跑一遍 TypeScript 官方测试集，重新生成兼容性矩阵；发现差异后，Agent 去两边代码里定位、构造最小复现、移植测试、提修复 PR。
同时团队还在推进几件事：和 Theo Browne 合作，把 tsc-rs 和 tsrs 合并成单一包，覆盖 TypeScript 的全部能力，包括 LSP 和 content mappers；以及为 Oxlint 的类型感知检查提供支持。
也就是说，AI 不只帮我们写业务代码，已经开始往底层工具链里钻了。
Cloudflare 的算盘不只是编译器
看看 Cloudflare 现在手里握着的前端工具链：
| 工具 | 定位 | 实现语言 |
|---|---|---|
| Vite | 前端开发与构建工具 | JS/TS（8.x 起内核由 Rolldown 驱动） |
| Rolldown | 打包工具 | Rust |
| Oxlint | 代码检查 | Rust |
| Oxfmt | 代码格式化 | Rust |
| tsrs | TypeScript 编译器 | Rust |
Vite 本身不是 Rust 写的，这点别搞混；但它的打包内核已经换成 Rust 了。随着 VoidZero 加入 Cloudflare，这几块正在拼成一条完整的链：从 CDN、Workers，到构建、检查、格式化、类型检查。
官方口径是 Cloudflare 上有超过 1000 万开发者在构建。这家公司确实不只是那个做 CDN 的公司了。
现在要不要试？
tsrs 已经开源，但仍是实验阶段，部分兼容性和语言服务还在完善。官方自己列了一条已知差异：诊断信息的打印顺序和上游不同，目标是稳定版发布前把差异压到最小。
想体验：
bash
npm install tsrs
npx tsrs**我的看法：普通业务项目短期内不用急着换，tsc 依然稳。**理由很简单------编译器这东西，行为差异比性能更致命。诊断顺序都还不一致的阶段，拿去卡 CI 只会给自己找麻烦。
但如果你关注边缘运行时、Wasm、AI Agent 沙箱，或者单纯对前端工具链的性能竞赛感兴趣，tsrs 值得盯一盯。
微软用 Go，Cloudflare 用 Rust，AI 又开始参与编译器开发。前端工具链这轮竞争，确实越来越有意思了。
------ 康小汪