2026 年 10 月 20 日，Cloudflare 推出 tsrs，启动将 TypeScript 移植到 Rust 的工作。TypeScript 作为面向 JavaScript 的静态类型语言，其编译器与相关工具原本主要用 TypeScript 编写；tsrs 的目标是把这套实现改用 Rust 重写，让类型检查、编译和语言服务等功能转移到 Rust 环境中运行，从而以 Rust 承载完整的 TypeScript 处理流程。

Cloudflare 和 VoidZero 目前正与 Owner.com 的 Max Schwenk 合作开发 tsrs，这是 TypeScript 编译器的 Rust 移植版。我们与 TypeScript 团队紧密协作推进这项工作，并将 tsrs 作为 Oxc JavaScript 编译器工具链的一部分进行孵化。

我们的目标是帮助开发者减少等待代码检查的时间，将更多精力投入构建。让 TypeScript 更快、更节省内存，也有助于把完整的开发环境带到更多场景中，包括直接在浏览器中运行。

需要说明的是，我们并不是在分叉 TypeScript。我们认为 TypeScript 团队应继续完全掌控这门语言的设计与发展方向。他们在推动 TypeScript 被 JavaScript 社区广泛采用的过程中，始终保持着长期愿景。我们不想改变这一点。

TypeScript 团队在很多事情上推进得很快，但某些特性他们可能会花数年时间有意地探索各种方案、制作原型，之后才选定合适的实现。Rust 移植版必须紧跟这些决策，否则最终会分崩离析并变得不兼容。我们必须严格基于 TypeScript 的原始实现来保留这门语言——而 TypeScript 团队应继续全权负责决定它该是什么样子。

性能与内存改进

我们对 TypeScript 的 Rust 移植版所做的早期基准测试结果很可观：在使用相同数量的类型检查工作进程时，tsrs 的速度最高提升至 TypeScript 7.0 的 8 倍，内存占用减少约 70%：

可以看到，TypeScript 的下一个版本已经带来了许多性能改进，使 TypeScript 7.1 beta 比 TypeScript 7.0 最快快 2.5 倍。其中一些优化是从 tsrs 向上游合并过去的，我们希望能找到更多。

你可能看过最近不同 TypeScript 移植版的各种性能基准测试，数据差异往往是因为使用了更大的机型以及不同于 TypeScript 默认值的选项。我们与 TypeScript 团队合作，确保上述基准测试是在相同配置下进行的比较。

默认情况下，tsrs 会附带一种依赖机型自适应配置，它占用更多内存，但速度更快：

尝试 tsrs

Rust 版的 TypeScript 旨在成为 TypeScript 的忠实移植。你可以通过 npm 安装实验版本：先执行 npm install tsrs，再运行 npx tsrs。

为什么是现在？

多年来我们看到了许多把 TypeScript 移植到其他语言的尝试。由于涉及的复杂性，只有一个移植成功了，那就是 TypeScript 团队把 TypeScript 从 JavaScript 移植到 Go 的版本。

然而，前沿 AI 模型现在几乎可以独立地在几天内完成大规模移植。我们已经看到了 slopforks、忠实移植版，以及用 Rust 或 C++ 完全重构的 TypeScript 版本。显然，市场对更快的 TypeScript 有明确需求。

为什么选择 Rust？

你可能会想：TypeScript 的 Go 移植版已经让 TypeScript 比之前用 TypeScript 写的版本快了 10 倍，内存效率也高得多。为什么这还不够？

然而，这不仅仅是速度的问题。Rust 提供了一些独特优势，比如在 WebAssembly 中运行。Rust 与 Wasm 的结合一直很强大，原因之一在于 Rust 语言设计的基础特性。把 Go 程序编译到 Wasm 时，必须把 Go 的垃圾回收器一起编译进去。而 Rust 的内存管理模型让 WebAssembly 的 guest 与 host 之间能够直接进行内存交互。这是 Rust 更适合 WebAssembly 场景的关键原因之一：内存效率。

Cloudflare Workers 支持 Wasm 已经有很长时间。就在几周前，我们宣布通过 wasm-bindgen 的新 Emscripten 目标，在 Workers 中支持原生 Rust。当你在 Workers 上以紧密循环的方式运行完整的软件构建和部署系统时，小内存占用的好处很快就能体现出来。这意味着你可以如此高效地运行这些工作负载，以至于现在能够在以前无法运行的地方运行完全封装的开发系统。

当与 agent 结合时，这带来了新的可能性：你现在可以在 Cloudflare 上完全沙盒化的环境中端到端地运行开发工具链。而借助 Wasm，你也可以在浏览器中安全地在客户端运行这些环境，或者运行在嵌入式设备、物联网应用中。

tsrs 移植版将如何维护？

首先，我们正与 Theo Browne 合作，将 tsc-rs 和 tsrs 合并成一个单一的包，支持 TypeScript 的所有功能，包括语言服务器协议（LSP）和 content mappers。

其次，我们在让 Vinext 与其上游 Next.js 保持同步方面取得了很大成功。我们在最近的一篇博文中解释了具体做法：

每天早上，一个 agent 会审查变更、获取 diff，并为任何可能影响 Vinext 的内容创建跟踪 issue。每天晚上，我们会在 Vinext 上运行 Next.js 测试套件，并重新生成兼容性矩阵。当其中一个测试或 issue 暴露出差距时，agent 现在能够识别两个代码库中的对应变更、构建复现用例、移植相关测试并提出修复。

我们将把同样的流程应用到 TypeScript 上，极其小心地确保不会引入与上游 TypeScript 不一致的行为。当我们发现性能改进时，会尝试把它们贡献回 TypeScript 的 Go 代码库，让所有人受益。

最后，我们承认目前与上游 TypeScript 版本存在一些差异，比如诊断信息的输出顺序。我们的目标是在发布稳定版时把这些差异降到最低。

下一步是什么？

Cloudflare 已经是许多支撑 JavaScript 生态的免费开源 Rust 工具的所在地，例如 Vite、Rolldown、Oxlint 和 Oxfmt。有超过 1000 万开发者在 Cloudflare 上构建项目，我们非常关心如何让底层开发者工具链变得更快、更可移植、更容易在更多地方运行。我们很期待尝试把 tsrs 更深入地集成到我们的技术栈中，比如在 Oxlint 中实现类型感知的 lint 规则。

就像 Vinext 一样，我们的目标是把 tsrs 作为一个维护良好、健康的开源项目来运营——而不会妨碍 TypeScript 本身。Oxc 团队已经开始重构代码库，使其更快、占用更少内存并且更易于维护。我们知道 TypeScript 团队也在认真对待这件事——他们正在试验针对 tsc 的内存和性能改进。我们很期待与 TypeScript 团队及 JavaScript 社区合作，共同构建最好、最快的 TypeScript 实现。

社区整体处在“兴奋但疲惫”的交叉情绪里：一边是 tsrs 带来的速度和内存改进让人眼前一亮，另一边是对“一切都用 Rust 重写”、人工智能几天生成大型移植以及同类 TypeScript 检查器不断重复的厌倦。真正分歧不在于 Rust 是否更快，而在于这些收益来自 Cloudflare 的特定 WASM 场景和具体优化、官方 TypeScript 会吸收多少，以及普通开发者到底要不要跟进。

认为 tsrs 让更快的 TypeScript 编译器变得可信

• 在大代码库里本地跑 TypeScript 一直很慢，而 tsrs 据称比 TypeScript 7.0 最多快 8 倍、内存少约 70%；有人实测它在多线程下内存表现很好，还保留了 bun 没有的增量检查，因此不少人觉得这条路值得认真对待，甚至直接喊话微软移植。（较多人） > 这个 Rust 移植比 TypeScript 7.0 最多快 8 倍、内存少约 70%，微软真该认真考虑把 TypeScript 移植到 Rust。（@AbuAssar）
• 在认可收益的同时，也有人希望官方或社区拉一个 TypeScript 7.2 实验分支，直接对比 tsrs 与官方版本的真实表现，而不是只看宣传里的倍数。（少数人）

认为普通项目不必急着切换，场景完全不同

• Cloudflare 的需求是在大规模场景下省成本、要跑几百万次编译，这和日常前端开发的迭代循环完全是两回事，所以你几乎肯定不需要立刻计划替换现有工具链。（较多人） > Cloudflare 要跑几百万次编译来省成本，和普通前端开发者的迭代循环完全不是一回事，你几乎肯定不需要马上计划切换。（@nsm）

认为加速不只来自 Rust 语言，官方会吸收优化

• TypeScript 团队成员表示，tsrs 很有意思，但他们自己做过 Rust 实验性移植，推测不少加速并不只是换语言带来的；tsrs 中发现的一些安全优化会被吸收进官方 TypeScript 7.1，Cloudflare 的 WASM 与 oxlint 整合也确实合理。因此不宜把 tsrs 读成“Rust 天生碾压 JavaScript/TypeScript”，它更像是特定约束下挖出的一套优化，还会回流到官方工具链。（高赞） > 我们自己做过 Rust 氛围式移植，怀疑不少加速并不只是语言选择带来的；tsrs 中发现的一些安全优化会进入 TypeScript 7.1。（@DanRosenwasser）

担心人工智能几天生成大型移植会削弱架构质量与人工投入的意义

• 虽然认可速度提升，但从“精心手写移植”转向“人工智能模型几天内几乎独立完成移植”让人不安：输出仍需要人审，因为架构决策往往不牢靠；如果一个人花一年做的语言项目能在几天被替代，手写和设计的价值会很难辩护。（少数人） > 我很高兴看到速度提升，但整个移植在几天内由人工智能完成、作者写了零行代码，让我担心架构决策的质量，也不确定以后花时间手写还有什么意义。（@egonschiele）

反感“万物皆可 Rust 重写”与同类项目重复造轮子

• 已经有 tsrs、tsgo-rs、bun check，甚至还有 C# 移植等多个同类 TypeScript 实现同时出现，有人觉得大家其实在造同一个东西；整体趋势像把一切都用 Rust 重写，令人疲惫。（较多人） > 现在的趋势似乎就是把所有东西都用 Rust 重写一遍。（@jdw64）
• 对 Rust 的狂热出现反弹，有人以玩笑口吻调侃 Rust 现在成了大家默认的“敷衍式”语言，甚至想换回 C。（少数人）

希望能力被收编进现有工具链，而不是再多一个新工具

• 虽然厌倦每天冒出新工具，但如果这类能力由 Vite 团队以 Vite+ 的形式提供，就能减少工具链决策、只维护一个配置，因此值得支持；否则只是又一个新选择。（少数人） > 我厌倦每天出现的新工具，但如果这基本是 Vite 团队在做、并能和 Vite+ 整合，我就支持，因为能少做工具链决策、只留一个配置。（@norman784）

有价值的补充

• Cloudflare 做 tsrs 的真实动机不是“用 Rust 写个更快的编译器”，而是需要一个能跑在纯 WASM 沙箱里的 TypeScript 编译器；把 Go 版 tsc 导出到 WASM 会带上完整 Go 运行时，改用 Rust 是为了绕开这个成本，速度更快只是副作用。（@sheepscreek）
• tsrs 采用了一种近似“模拟垃圾回收”的内存模型：用永不释放的内存池管理长生命周期对象，绕开 Rust 没有垃圾回收机制、从带垃圾回收的语言移植时通常要重构数据结构的难题；这种做法是否完全符合 Rust 的安全要求、足够可靠，仍值得观望。（@afdbcreid）
• 在单体仓库上实测对比显示，tsrs 增加线程时内存表现很好，并支持 bun 没有的增量检查，但单论效率仍不及 bun。（@jscheel）