LLM 把整个 TypeScript 编译器搬进 Rust，到底值不值——181711 个测试全过，VS Code 375 万行检查从 54.56 秒降到 4.20 秒

微软用 Go 重写 TypeScript 编译器之后，一个作者自称「一行代码都没读过」的 Rust 版本在 10 月 7 日挂上了 GitHub：ts-rust（npm 包名 tsc-rs），181,711 个从 Go 版移植过来的测试全绿，6 个真实开源项目的类型检查几何平均比 tsc 7 快 1.61 倍，VS Code 375 万行代码从 54.56 秒降到 4.20 秒——两天时间拿到 681 颗星，HN 上 106 分、206 条评论。

先看数字：它到底快在哪

README 给了 6 个开源项目的全量类型检查对比（Apple M4 Pro 12 核 48GB、macOS 26.5.1、hyperfine 5 次取中位数、--noEmit --incremental false，倍数是对 tsc 6 的加速比）：

三句话读完这张表：

• 对比 tsc 6（跑在 Node 上的老编译器），Rust 版几何平均 11.4 倍，VS Code 这种 375 万行的仓库从 54.56 秒到 4.20 秒；
• 对比 tsc 7（微软自己的 Go 版），Rust 版 快 1.61 倍，也就是同样的活儿再省掉约 4 成时间；
• bun check 更快（20.9×，比 Go 版快 2.95 倍），但 Bun 那条路跑不了 Effect 诊断，Effect 项目得再跑一遍。

一个容易被忽略的细节：tsc 6 在 VS Code 和 Sentry 上默认堆内存会直接 OOM，测试时必须用 Node 24.19 + 16GB heap 才跑得完——这本身就是「老编译器撑不住现代仓库」的证据。

它和 TypeScript 7 是什么关系：移植，不是重写

ts-rust 钉死在 microsoft/TypeScript 的 673a5f17（2026-09-29，TypeScript 7.1.0-dev）这一个上游提交上，保留 Go 版的算法和行为，命令行、语言服务器、API 都对齐，官方给的验证口径是：

• TanStack Query core 和 Hono 的诊断输出与 Go 版逐条一致；
• 181,711 个从 Go 移植过来的测试全部通过；
• 60 个开源项目上类型检查耗时约为 Go 版的一半（几何平均）；
• 120 个仓库的命令行输出与 Go 版差异，只在 README 列出的几条里。

也就是说，它不是「另一个类型检查器」，而是把 Go 那份实现换了个语言重新生成了一遍——所以「换过去会不会改行为」这个最要命的问题，用上游测试集直接兜住了。

before/after：AI 移植这件事本身也有 before/after

这是这篇最值得看的部分，因为仓库里的 docs/history.md 把三次失败都留着：

作者的原话是：这 24,047 美元相当于他 200 美元订阅套餐周额度的 925%~983%。而且 README 里专门用一条「The Slop Line」标注：这条线以下的内容全部由 LLM 写的，他自己一行没读。

顺带一提，HN 那 206 条评论基本在吵两件事：一是 42 万和 2.4 万这两个数口径不同（一个是 API 定价、一个是实际订阅消耗），二是「你们没读过代码就敢往 CI 里塞？」——后者正是下面这段要说的。

代码上下文：在什么场景下替换、怎么替换

场景：你的 CI 或本地脚本里有一条 tsc --noEmit，Node 起进程 + 类型检查占了流水线一大半时间，但你不想动 package.json 里的 typescript 依赖（下游插件、Volar、vue-tsc 都还认它）。

# 老写法：跑在 Node 上，VS Code 这种仓库要 54.56s
npx tsc -p tsconfig.json --noEmit

# 新写法：原生二进制，同一份 tsconfig，4.20s（M4 Pro 实测）
npm install -D tsc-rs
npx tsc-rs -p tsconfig.json --noEmit

tsc-rs 收的参数和 tsc 完全一样，npm 包名故意错开成 tsc-rs，不会和 typescript 打架；每个 release 还带独立的 tsc 二进制 + lib 文件压缩包，CI 里可以不走 npm 启动器（测试中 tsc 7 和 tsc-rs 就是按原生二进制跑的）。目前平台支持 Linux x64（静态编译，任意发行版）和 macOS arm64，Windows 和 Linux arm64 还没出。

如果你用 Effect，它把 Effect 的语言服务诊断（错误码 377xxx）直接编译进了同一次检查，等于少跑一个编译器——但要在 tsconfig 里声明插件才会启用：

{
  "compilerOptions": {
    "plugins": [{ "name": "@effect/language-service" }]
  }
}

带 Effect 诊断时的对比更夸张：tsc-rs 11.13 秒，tsc 7 + @effect/tsgo 21.07 秒，tsc 6 + 官方 JS 插件 138.63 秒。

已知问题：别一上来就全量替换

README 的 Known problems 写得很实：

• 有的 monorepo 里同一个源文件既能通过 node_modules 又能通过直接 import 到达，tsc-rs 可能多写出一些文件并报 TS6059；巧的是 tsc 自己对这个的判定靠时序，结果每次运行都不一样，而 tsc-rs 每次都稳定复现 TypeScript 6 的结果；
• tsc -b 下如果项目之间没写 project reference，它可能读到旧的或缺失的产物（TS2305/TS2307），补上 reference 即可；
• 编辑器长会话内存缓慢增长，约 每 1000 次编辑 +20 MiB，起点比 tsc 高 12%~24%，但从第 20 次编辑起就低于 tsc（实测到 2190 次编辑）；
• tsc-rs --version 打印的是它移植的 TypeScript 版本（7.1.0-dev），不是 npm 包版本，typesVersions 匹配也按它算。

另外它目前是 0.1.0 的早期版本，四个项目要先改配置才能在 tsc 7 下零报错（Excalidraw 去掉 baseUrl、TypeORM 的 moduleResolution 改 nodenext 等）——这些是 TypeScript 7 本身删掉的东西，不是 Rust 版的锅。

下一步：今天就能做的一件事

在 CI 里加一条影子任务，不替换、只对账：

- name: type-check shadow
  run: |
    npx tsc -p tsconfig.json --noEmit > tsc.log 2>&1 || true
    npx tsc-rs -p tsconfig.json --noEmit > tsc-rs.log 2>&1 || true
    diff <(sort tsc.log) <(sort tsc-rs.log)

先确认你项目的报错集合和 tsc 一致，再把它挪进快速通道（比如 PR 阶段用 tsc-rs、主干仍留 tsc）。Windows 用户这周先等平台包，别急着上。

数据来源：pingdotgg/ts-rust README 与 docs/history.md（2026-10-07 建仓，MIT，681 star）、GitHub API、Hacker News「Port of the TypeScript compiler, checker and lsp to Rust, by LLM」（106 分 / 206 评论，2026-10-08）。基准均为作者在 M4 Pro 上用 hyperfine 5 次取中位数测得，预览包 CI 构建未开 PGO/BOLT，实测只会更快。