TypeScript 有了 Rust 心脏：tsrs 快 8 倍，而保持同步的是一群 agent

2026 年 10 月 20 日，Cloudflare 在官方博客宣布：tsrs——一个用 Rust 完整移植的 TypeScript 编译器——正式亮相。这不是又一个"重写 tsc"的社区实验：它由 Cloudflare 联合 VoidZero、Owner.com 的 Max Schwenk 共同推进，被孵化进 Oxc 工具链，更重要的是，TypeScript 官方团队全程参与协作，且双方明确表态——这不是 fork，语言的设计权依然百分之百属于 TypeScript 团队。

更值得咀嚼的不是"Rust 比 Go 快"这个标题党数字，而是博客里最不起眼的一节：tsrs 团队打算沿用 Cloudflare 维护 Vinext 的 agent 流程——每天早晨一个 agent 审查上游变更、开 tracking issue，每晚重跑兼容矩阵，发现 gap 时 agent 自己跨代码库定位、写复现、移植测试、提 fix。TypeScript 慢了十年没解决的同步问题，这一次是被 AI 连夜搬走的。本文先还原事件，再把"agent 维护"这件事拆开讲透。

发生了什么：tsrs 到底是什么

一句话定义：tsrs 是 TypeScript 编译器（及语言服务器）的 Rust 移植，目标是成为 TypeScript 7 的 drop-in replacement——装上就能用，行为要跟官方实现严格一致。GitHub 仓库 oxc-project/tsrs 已公开（Apache-2.0），官方形容自己的目标是 100% conformance。

这件事的"人"值得列出来，因为它们决定了这不是 slopfork：

• Max Schwenk（Owner.com）：移植的最初作者。动机很现实——Owner.com 的 TypeScript 代码库大到"常规类型检查贵到限制了能同时跑几个 coding agent"，他把编译器搬进 Rust 是为了解决自己的账单问题。
• Cloudflare + VoidZero：前者有 Workers 与 Wasm 生态要铺，后者是 Vite、Rolldown、Oxlint、Oxfmt 背后的 Oxc 工具链团队。tsrs 被"孵化进 Oxc 工具链"，意味着它未来要和 Rolldown、Oxlint 等拼成一条完整的 Rust 前端工具链。
• TypeScript 官方团队：密切协作。Cloudflare 在博客里两次强调"not forking"——语言设计权不动，移植必须"严格基于原始实现"。这是一个罕见的姿态：移植方主动把方向盘交还给上游。
• Theo Browne：Cloudflare 正在和他合作，把 tsc-rs 与 tsrs 合并成一个包，目标是支持 TypeScript 的全部功能，包括 LSP 和 content mapper。

把 tsrs 放进 Oxc 的版图里看，野心更清楚。Cloudflare 博客点名了自家已有的 Rust 工具链资产：Vite、Rolldown、Oxlint、Oxfmt——打包、lint、格式化都已经是 Rust 的了，缺的正是"类型检查"这一块。tsrs 补上之后，一条从解析、检查、打包到 lint 的全 Rust 前端工具链就闭环了。博客还透露了下一步：把 tsrs 更深地集成进自家技术栈，比如 Oxlint 的 type-aware（类型感知）lint 规则。类型感知的 lint 一直是个奢侈品——慢、吃内存，很多规则不是写不出来，是跑不起；如果类型检查本身快一个数量级，这些规则就变得可行。这可能是 tsrs 落地最快的场景，比"替换 tsc"更早到来。

一个实验版已经可以试了：npm install tsrs，然后 npx tsrs。仓库还提供了一个浏览器 playground（tsrs-playground.void.app），可以直接在线检查和 emit 代码。

性能数字怎么读：8 倍快、70% 内存，但别急着转发

博客给出的 headline 数字是：同等类型检查 worker 数下，tsrs 比 TypeScript 7.0 快最高 8 倍，内存少约 70%。先把丑话说在前面：这是 Cloudflare 的厂商自测（博客原文措辞是 "Early benchmarks ... are promising"）。Cloudflare 声称已和 TS 团队对齐了测试配置——"确保对比的是同一配置"，第三方媒体 RuntimeWire 也在报道中标注了 "early performance claims still self-reported"。所以正确的读法是：方向可信、幅度待第三方复现。

但自测的细节其实相当扎实，值得细看。博客配了两张对比表，测试命令是 -p <project> --noEmit --incremental false --pretty false --checkers 4，在 VS Code、MUI docs、webpack、t3code server 四个真实项目上跑。几个有信息量的点：

• MUI docs 上 8.10 倍（1.29s vs 7.0.2 的 10.44s），t3code server 上 8.08 倍——"最高 8 倍"不是 cherry-pick 单个数字，至少两个项目跑出了这个量级；
• VS Code 上只有 3.83 倍（1.73s vs 6.62s），说明收益和项目结构强相关，别把 8x 当成普遍承诺；
• 内存侧更稳定：VS Code 上峰值内存 1.78 GiB vs 7.0.2 的 7.68 GiB（0.23x），四个项目全部在 0.13x–0.31x 区间，内存收益比速度收益更一致；
• TypeScript 7.1 beta 本身已经比 7.0 快最高 2.5 倍，而且博客承认"其中一些优化是从 tsrs 反哺回上游的"——tsrs 在和官方赛跑的同时，也在给官方送弹药。

还有一个第三方视角可以对照。Bun 1.4.3 发布时做过一组独立测试（64 核机器，VS Code 代码库）：tsrs 0.53s / 2.64GiB，tsc 7（tsgo 7.0.2）9.79s / 7.52GiB，bun check 0.87s / 2.86GiB。但同一篇报道也给了关键限定：默认线程数不同（tsgo 只用 4 线程，bun check 用满全部核心）；统一给 16 线程后，tsgo 降到 4.54s、bun check 1.49s——"差距是真实的，但比默认配置下看起来小"。这个提醒对 tsrs 同样适用：并发配置是这类基准里最容易被做手脚的变量，看任何"快 N 倍"先问线程数。

还有一个官方自己披露的细微差别：博客里其实有两张表。前面引用的都是"同等配置"对比——为了公平，所有编译器用同样的 worker 数；而默认情况下，tsrs 会按机器类型自适应调参，"用更多内存但更快"。记住这个区别：8x/70% 是"公平模式"下的数据，默认模式的取舍不同。以后看到第三方拿 tsrs 默认配置对比 tsc 默认配置的数字，先问双方各用了多少内存、多少线程——这正是 Cloudflare 自己在博客里的提醒："市面上各种移植版的性能宣称，常常是因为用了更大的机器和不同的选项"。

为什么是 Rust：Go 版 TypeScript 还不够好吗

这是个好问题，因为 TypeScript 团队自己已经把编译器从 JavaScript 搬到了 Go（TS 7.0），Cloudflare 自己的说法是 Go 版"比旧的 JS 版快了 10 倍、内存效率大幅提升"。那为什么还要再搬一次？

Cloudflare 给出的理由不在"更快"，而在 WebAssembly。Go 程序编译到 Wasm 时，必须把 Go 的垃圾回收器一起编进去；而 Rust 的内存管理模型让 Wasm guest 和 host 之间的内存交互非常直接——这是 Rust 更适合 Wasm 场景的关键。结合 Cloudflare 的算盘看：Workers 早就支持 Wasm，不久前他们又宣布了 Workers 原生支持 Rust（wasm-bindgen 的 Emscripten target）。当整个构建和部署系统在 Workers 上以 tight loop 运行时，小内存占用的复利非常可观——小到可以把"完整封装的开发系统"塞进以前跑不动的地方：浏览器里、沙箱里、嵌入式设备和 IoT 上。

这句话翻译成开发者语言就是：以后你可能在浏览器标签页里跑一个完整的、带类型检查的 TypeScript 开发环境，而不需要把代码发到云端。这也是博客里那句"帮开发者少等类型检查、多写代码"之外，真正面向未来的赌注。

另外博客补了一个时代注脚，值得原样引用："frontier AI models can now do large-scale ports almost independently in a matter of days."（前沿 AI 模型现在几天内就能近乎独立地完成大规模移植。）这些年移植 TypeScript 的尝试很多，之前唯一成功的只有 TypeScript 团队自己从 JS 到 Go 的那次；现在 Rust、C++ 的"slopfork、忠实移植、完全重构版"已经遍地都是。换句话说，移植本身不再是护城河，对移植的"持续维护"才是——这就引出了本文真正的重点。

为什么前端开发者要在意：类型检查是一笔隐形税

先说一个每个前端都交过的税：大型单仓里跑一次 tsc --noEmit，几分钟是常态。CI 流水线里类型检查常常是最长的那一步；编辑器里你改完一行，红线要转半天才跟上。这些时间不写在任何工时统计里，但每天都在发生。VS Code 仓库在官方基准里从 6.62 秒降到 1.73 秒——别小看这 5 秒，它是"保存即反馈"和"保存后去泡咖啡"之间体验的分水岭。

内存侧的意义更实在。7.68 GiB 的峰值内存意味着你的 CI runner 得是高配机器，笔记本风扇得起飞；而 1.78 GiB 意味着更便宜的 CI 配置、同一台机器上能并行更多任务。对独立开发者和小团队，这是真金白银的成本差。

但最大的变量是 agent 时代。RuntimeWire 在报道里点出了 Schwenk 的原始动机：Owner.com 的代码库大到"常规类型检查贵到限制了能同时跑几个 coding agent"——每个类型检查器都在和 coding agent 抢内存、抢 CPU。当 AI 写代码只要 10 秒、tsc 检查却要 3 分钟，瓶颈就从"写代码"转移到了"验证代码"。tsrs 的真正用户画像，可能不是"嫌 tsc 慢的人类"，而是"嫌 tsc 占资源的一大群 agent"。一个内存少 70%、速度快数倍的类型检查器，意味着同一台机器上能多跑几倍的 agent 并行任务——这正是 Cloudflare 把"完整开发环境塞进 Workers 沙箱"的算盘。

还有一层容易被忽略的意义：tsrs 对官方不是零和竞争，而是一个外部性能实验室。TS 7.1 beta 比 7.0 快最高 2.5 倍，其中部分优化就是 tsrs 反哺的。历史上移植项目和上游多是"分叉—决裂—各自为政"的剧本，tsrs 选的是"赛跑 + 输血"：自己往前冲，优化往回送。这种关系能成立，恰恰因为开头那句"not forking"的承诺——语言设计权不动，移植方就没有分裂的动机。对开发者来说，这意味着无论最后谁赢，TypeScript 只会更快。

真正的新闻不是 Rust，是"谁来保持同步"

任何编译器移植的坟墓都叫"上游漂移"：TypeScript 团队每个版本都在加特性、修 bug，移植版只要几个月跟不上，就会悄悄变成"另一种语言"。Cloudflare 在博客里花了一整节讲 tsrs 打算怎么活下去，而答案不是"招更多人"，是让 agent 接管上游同步。

这套流程是 Cloudflare 维护 Vinext（Next.js 的社区 fork/兼容实现）时已经跑通的，博客原文引用如下：每天早晨，一个 agent 审查上游变更、拉取 diff，为任何可能影响 Vinext 的变更开 tracking issue；每天晚上，兼容矩阵重新生成——把 Next.js 的测试套件跑在 Vinext 上。当某个测试或 issue 暴露出 gap，agent 会跨两个代码库定位那次变更、写出复现、把相关测试移植过来、然后提出 fix。

tsrs 准备把同一套流程套到 TypeScript 上，并承诺"极端谨慎，不引入与上游行为的分歧"；遇到性能优化就尝试贡献回 TypeScript 的 Go 代码库——"让所有人受益"。注意这个闭环里人类的角色：定规则、审 fix，而不是逐行跟进上游 commit。编译器大战的终局可能不是语言之争，而是"谁先让 agent 接管上游同步"的组织能力之争。上游漂移曾是所有移植项目的死因，而 agent 恰好擅长这种"高重复、强规律、跨代码库 diff"的脏活累活。

再往深一层，这套 agent 流程真正解决的是移植项目里最磨人的部分：判断"上游的哪次变更会影响我"。TypeScript 每个版本有成百上千个 commit，人类维护者靠经验和 changelog 筛选，漏掉一个就可能引入静默分歧。agent 的做法是反过来的：不预判，先全量跑——每晚把上游整个测试套件在 tsrs 上重跑一遍，用测试失败来反推"哪些变更没跟上"。这是一种"用计算换判断"的思路：测试矩阵就是 ground truth，gap 自己会浮现。晨间的 tracking issue 负责"已知风险"，夜间的矩阵负责"未知风险"，两者互为备份。这也是为什么 Cloudflare 敢说"极端谨慎"——谨慎不靠人工细心，靠流程冗余。对任何想复制这套方法的人，记住这个设计哲学：别让 agent 去"理解"上游，让测试矩阵去"裁决"上游。

对 vibe coding 的读者来说，这一节的含金量其实超过 8 倍这个数字：它给出了一个"agent 维护大型移植项目"的可复制模板——晨间审查（变更分类）→ tracking issue（任务分解）→ 夜间矩阵（回归验证）→ gap 驱动的定位/复现/移植测试/提 fix（自主修复）。如果你在维护任何需要跟随上游的项目（框架 fork、API 兼容层、多语言 SDK），这套流程今天就能抄。

更值得玩味的是这套流程的"进化史"。Cloudflare 先是在 Vinext 上验证了"agent 守上游"的可行性——那是 Next.js 生态，变更频繁、社区驱动；现在他们把同一套方法论搬到 TypeScript 编译器上——这是语言基础设施，正确性要求高一个数量级。从框架兼容层到编译器，agent 维护的版图正在从"外围工具"向"核心基础设施"推进。如果 tsrs 能在未来一年里跟上 TypeScript 的版本节奏而不出现分歧，它将成为"agent 可以长期维护关键基础设施"的第一个大规模公开证据。这比 8 倍这个数字，对行业的冲击更大。

诚实提醒：实验版、五条细则

热闹归热闹，以下五条是动手前必须知道的：

• 实验阶段，行为有差异：博客自己承认，目前和上游的差异之一是 diagnostics 的打印顺序；目标是在 stable 版时把差异压到最小。仓库 README 则说"在现有项目的测试中尚未发现 tsrs 的正确性 bug"——这是仓库自述，实验阶段请按"待验证"理解。
• 部分功能暂不支持：--init 和 --showConfig 目前不可用；LSP 与 content mapper 要等 tsc-rs 合并完成后才完整。
• 基准是厂商自测：8x/70% 的测试配置据称与 TS 团队对齐，但项目选择、机器、调参都是 Cloudflare 定的；第三方独立复现（如上面 Bun 那组数据）显示方向一致、幅度受线程配置影响大。
• 官方在追赶，差距可能缩小：TS 7.1 beta 已比 7.0 快最高 2.5 倍，且吸收了 tsrs 反哺的优化。tsrs 的领先窗口有多大，取决于它"反哺上游"的速度和"保持领先"的速度哪个更快——这是个动态博弈，不是一次性结论。
• 诊断顺序差异不只是"显示问题"：依赖错误输出做 snapshot 测试的工具链可能受影响。仓库 README 提到可用 --checkerAssignment go 等 flag 让行为更逼近上游——说明"一致"是个可调参数，而非开箱即得，迁移前要在自己的测试矩阵里验证。
• 贡献通道是单向的：仓库 issue tracker 开放报 bug（要求带最小复现），但 PR 是关闭的——"没带宽 review"。想参与代码贡献，现阶段此路不通。

开发者现在能做什么

• 尝鲜：npm install tsrs 后 npx tsrs --noEmit 跑一下自己的项目，对比耗时和峰值内存；也可以先上浏览器 playground（tsrs-playground.void.app）零成本试。
• 盯住 conformance：仓库的兼容性证据页（compatibility and evidence）列了支持的功能和已知 gap，bench/RESULTS.md 有持续更新的基准数据，release notes 记录每个实验版的进展；stable 版的目标是"对齐 TS 7.1 + 100% conformance"——这个目标达成之日，才是生产环境考虑切换的起点。
• 评估 Wasm 场景：如果你在做浏览器内 IDE、边缘函数里的类型检查、或嵌入式设备的 JS 工具链，@tsrs/wasm（wasm32-wasip1）值得放进技术雷达。
• 抄作业：把"晨间审查 + tracking issue + 夜间兼容矩阵 + gap 自主修复"这套 agent 流程，套用到你自己要跟随上游的项目上。这是 tsrs 留给 vibe coding 社区最现成的礼物。

最后补一个时间维度的判断。TypeScript 7.1 目前还是 beta，而 tsrs 的 stable 版瞄准的对齐点正是 7.1——这意味着未来几个月会出现一个罕见的"三方同跑"窗口：官方 Go 版、tsrs Rust 版，再加上 Bun 的 bun check，三家在同一个语言版本上拼性能、拼兼容。对开发者这是好事：竞争会逼出更诚实的基准（线程数、内存、项目选择都会被放在显微镜下），也会加速优化在三方之间的流动。编译器大战的下半场，才刚刚开始。

还有一个值得记录的细节：仓库 README 底部写着"Not affiliated with or endorsed by Microsoft"（与微软无关、未经微软背书）。这不是客套，而是"not forking"承诺的注脚：tsrs 是 TypeScript 的衍生作品、Apache-2.0 许可证，捆绑的 lib.*.d.ts 仍归 TypeScript 所有，致谢名单里专门感谢了 TypeScript 团队。开源世界里，许可证和致谢的写法，往往比 PR 更能说明一段关系的真实质地。

最后回到开头的判断：tsc 慢了十年，社区等来的不是又一次"更快的重写"，而是一次"被 AI 连夜搬走"——移植用几天，同步交给 agent。Rust 只是这次搬家的卡车，真正上路的是 agent 维护大型代码库的新范式。卡车会换，范式会留下。