北京
流传最广的误解是 TypeScript“原生化”了，仿佛 .ts 文件可以直接在浏览器或 Node 里跑起来，构建步骤从此消失。现实恰恰相反——浏览器仍然看不懂 TypeScript，Node 也不会做类型检查。真正变“原生”的不是你的代码，而是编译器本身。这反而是更有价值的变化。
“原生”到底指什么？TypeScript 从诞生起就一直用 TypeScript 编写。你每天在 CI 里跑的 tsc，编辑器里吐出红色波浪线的 tsserver，本质上都是跑在 Node.js 上的 JavaScript 程序。当编译器在处理百万行代码库的类型检查时，它自己在单线程里吃力地遍历一个布满指针的类型对象图，还要扛着 JIT 预热和垃圾回收的压力。
TypeScript 7 用 Go 重写了整套编译器并预先编译成了原生二进制。微软的首席架构师 Anders Hejlsberg 在 2025 年 3 月公布了这项移植计划，最终在 2026 年 7 月 8 日随 TypeScript 7.0 正式发布。用一句话概括：过去 .ts 代码进到一个 JavaScript 写的编译器，跑在 Node 上，出来类型错误和 .js 文件；现在 .ts 代码进到一个 Go 原生二进制，出来的仍然是同样的类型错误和同样的 .js 文件。输入和输出没变，变的只有中间那个环节。
这已经足够成为一件大事，因为编译速度出现了数量级的跃升。微软发布的完整构建基准测试给出了明确数字：Visual Studio Code 的 150 万行代码从 77.8 秒降至 7.5 秒，TypeORM 从 17.5 秒降到 1.3 秒，tRPC 从 5.5 秒降至 0.6 秒。10 倍上下的提升在不同规模的项目上保持得相当稳定，说明这不是某种只对大仓库生效的缓存技巧，而是实实在在的基线被拉高了。
值得一提的细节是：10 倍的收益并非完全来自从 JIT 编译 JavaScript 到提前编译 Go 的转换。另一个重要部分是共享内存多线程，这是旧编译器在结构上根本无法做到的。JavaScript 的 Worker 线程不能共享对象图，只能靠消息传递和数据拷贝。而类型检查器的核心工作恰恰就是在同一个巨大的类型共享图上反复遍历，过去一直被限制在单核上。现在 Go 版本的检查器能把工作分摊到并行 Worker 上，所有 Worker 都在读取同一块内存。
TypeScript 7 直接把这个能力暴露了出来。默认就启用 4 个类型检查 Worker，还可以在 CI 的强力机器上调高并行度：npx tsc -p tsconfig.json --checkers 8。微软的测试显示，当 Worker 数调到 8 时，VS Code 的基准时间再降到 7.51 秒，相比旧编译器达到 16.7 倍的原地提升。
所以标题里那个“原生”应该被完整理解成“原生编译的 TypeScript 工具链”。你的 .ts 文件仍然需要被转译成 JavaScript 才能运行，仍然需要一个构建步骤。但这套构建步骤突然变得快了一个数量级，而且伴随着可配置的并行度，大型代码库的反馈循环被极大地压缩了。对开发者来说，这种变化比“原生运行”的幻想来得更实在。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
