微软近日分享了TypeScript 7（代号为 Corsa 项目）的最新进展，披露了对 TypeScript 编译器的一次根本性重构。该更新发布于2025年12月，详细介绍了团队将 TypeScript 编译器用 Go 语言重写的宏伟计划，他们承诺构建速度最高可提升 10 倍，并显著降低内存的占用。
这款名为tsgo的全新原生编译器充分利用了 Go 语言的性能优势，带来了大幅度的速度提升。据 TypeScript 团队表示，与旧版本相比，完整构建速度最高可提升 10 倍，并具备高效的多项目并行处理能力。为编辑器功能（如代码补全、跳转定义、重构等）提供支持的原生语言服务目前已基本稳定，可供日常使用。
用户现在就可以试用这一预览版：
npm install -g @typescript/native-preview
TypeScript 7 最重要的变化之一是默认启用严格模式（strict mode），这是一项与以往版本不兼容的破坏性变更。这一转变体现了团队对类型安全的坚定承诺，也符合行业最佳实践，但可能要求从旧版本升级的项目进行相应调整。
选择 Go 作为实现语言在开发者社区引发了广泛讨论。团队在一份详尽的FAQ中解释说，Go 提供了自动垃圾回收机制，同时又是目前最贴近“原生优先”理念的语言。此外，现有 TypeScript 代码库采用高度函数式的编程风格，几乎不使用类，因此 Go 的函数与数据结构范式比面向对象语言更为契合。
在Hacker News上，开发者们对性能提升表现出了极大的热情。一位用户评论说：
哇，这太震撼了！10 倍的速度提升对我们这类大型 TypeScript 项目将是颠覆性的。我一直在等待这样的改进，我们团队的项目在 CI 上的类型检查耗时极长，并严重拖慢了 IDE 的响应速度。
不过，也有开发者对依赖 TypeScript 编译器 API 的工具迁移路径表示担忧：
……对于我们这些工具作者来说，这个原生编译器将如何分发？我猜会通过 WebAssembly（WASM）？编译器 API 是否兼容？比如转换器（transforms）、抽象语法树（AST）、LanguageService、Program、SourceFile、Checker 等等？
我非常担心工具生态的迁移可能会异常困难。
一些开发者已经上手尝试。Reddit 上有用户称其类型检查时间减少了 75%。还有人对默认开启严格模式表示欢迎：
默认启用严格模式真是太棒了。我们以前经常在项目中工作到一半才发现严格模式没启用，结果要修复一大堆问题，非常令人头疼。
对于重度依赖编译器的开发工具而言，TypeScript 7 的原生实现使其与其它以原生语言编写的高性能 JavaScript 工具站在了同一赛道。例如，用 Go 编写的esbuild，以及用 Rust 编写的 SWC 和 oxc，均已证明原生实现能带来显著的性能优势。TypeScript 团队此次转型不仅验证了这一架构方向的正确性，同时也确保了与 TypeScript 语言规范的完全兼容。
TypeScript 是由微软开发和维护的一种强类型编程语言，它在 JavaScript 基础上增加了静态类型定义。自 2012 年发布以来，TypeScript 可编译为纯 JavaScript，运行于任何支持 JavaScript 的环境，包括浏览器、Node.js 及其他 JavaScript 运行时。通过其类型系统，开发者能在编译阶段而非运行时捕获错误；借助智能代码补全、重构等特性，IDE 支持也得到了显著增强，同时，显式的类型契约使大型代码库更易于维护。
原文链接：
