TypeScript 的编译器正在被重写一遍，语言是 Rust。这件事由 Cloudflare、VoidZero 和 Owner.com 的 Max Schwenk 共同推进，产物叫 tsrs，挂在 Oxc 这条 JavaScript 编译器工具链里孵化。早期数据：同等配置、同等类型检查 worker 数量下，比 TypeScript 7.0 快 8 倍，内存少 70%。
先把定位钉死。tsrs 不是 fork。Cloudflare 的原话是 TypeScript 团队应当继续掌握语言设计与方向，这一点不该被移植版动摇。所以 Rust 版只能严格贴着上游实现走。TypeScript 团队为一个特性可能磨几年原型才定稿，移植版一旦自作主张，分叉就是时间问题。
基准数字背后的口径问题
8 倍和 70% 这两个数，是和 TypeScript 团队一起核过的同配置对比。市面上已经冒出若干”性能炸裂”的 TS 移植宣传，不少是换了更大的机器规格、开了不同编译选项跑出来的。tsrs 的口径是 worker 数量对齐。另外 TypeScript 7.1 beta 自身已比 7.0 快 2.5 倍，其中一部分优化正是从 tsrs 上游回馈进 Go 代码库的。
有人会问：Go 移植版已经快了 10 倍，Rust 版图什么。答案在 Wasm。
为什么非得是 Rust 加 Wasm
Rust 的内存管理模型让 Wasm guest 与 host 之间的调用很直接。Go 程序编译到 Wasm 要把垃圾回收器和运行时一起打包进去，包体与启动开销都跟着涨；Rust 没有这层负担。Cloudflare Workers 早已支持 Wasm，前阵子又补了原生 Rust 支持，走的是 Emscripten target 的 wasm-bindgen。
落到工程细节上，Rust 侧目标三元组的选择会直接改变产物形态。wasm32-unknown-unknown 产出的是无系统接口的裸模块，适合浏览器里由 JS 胶水层驱动；wasm32-wasip1 带 WASI 系统调用约定，适合 Workers、边缘函数这类有受控文件与时钟接口的环境。选错目标，要么链接失败，要么运行时拿不到需要的系统能力。这也是 tsrs 能同时谈”浏览器内”和”边缘沙箱”的前提——同一套 Rust 代码按目标分别编译。
能跑进浏览器意味着什么
以前不现实的事现在有了路径：完整开发环境跑在浏览器里、嵌入式设备上、IoT 应用里。Cloudflare 的说法是把整套构建与部署系统塞进 Workers 的紧循环，内存占用小的优势立刻兑现，甚至能在完全沙箱化的环境里端到端跑工具链。放到 Agent 场景，就是在一个隔离沙箱里跑完整开发链，或者在客户端浏览器里安全执行。
路线图与集成边界
tsrs 会和 Theo Browne 的 tsc-rs 合并成一个包，目标是覆盖 TypeScript 全部特性，包括 LSP 和 content mappers。同步策略参照他们维护 Vinext 与 Next.js 的方式，不允许出现与上游的偏差；性能改进尽量回馈给 TypeScript 的 Go 代码库。
alt=”tsrs 把 TypeScript 编译链搬进 Rust 与” />
集成层面有个容易踩的点：合并后对外只保留一个包名，旧包名一般只做转发，不再独立发版。项目里同时出现两个包名时，锁文件会拉进两份实现，类型检查结果和报错行号可能对不上。另外 Oxc 工具链里 tsrs 是以独立 crate 的形式接入，并非直接把 tsc 的调用点替换掉，所以现有基于 tsc CLI 参数的脚本不能假设参数完全等价，迁移前先跑一遍自己的构建脚本验证。
现在 npm install tsrs 就能试实验版，在沙箱里跑工具链。
alt=”tsrs 把 TypeScript 编译链搬进 Rust 与” />
真正的价值不在”又多了个快 8 倍的 TS”。在于 TypeScript 第一次具有在浏览器和边缘环境完整运行的条件。开发工具链不再绑死本地重型机器，而是能进浏览器、进 Workers、进 Agent 沙箱——开发环境的形态会跟着变。
参考来源：
Cloudflare Blog：Introducing tsrs, a Port of TypeScript to Rust
https://github.com/oxc-project/tsrs
ID:6634
