Enivia 前几天，TypeScript 正式发布了 7.0 RC 版本。耗时一年多的 Go 语言重置版 TypeScript 终于离我们越来越近了！
回顾一下
这次底层改写的核心目的，就是解决 TypeScript 在大型代码库中的性能上限问题。
过去 TypeScript 编译器直接由 TypeScript 编写，再运行在 JavaScript 引擎之上。
这种模式虽然便于自举和维护，但在百万行级别项目中，类型检查、编辑器启动、自动补全、跳转定义、查找引用都会很慢。
早在一年多以前，TypeScript 开发团队就在官网上发布文章，宣布接下来的目标会集中在性能提升上。为此，团队从去年 3 月开始了 TypeScript 编译器和工具的原生移植。
对接触 TypeScript 最多的前端开发群体来说，最直接的变化就是速度提升。
前端开发速度提升
现代前端项目往往包含 React、Vue、Next.js、Vite、Monorepo、组件库、Node 服务端代码和复杂第三方类型声明等等。
项目越大，TypeScript 类型往往越有价值，但类型检查成本也越高。Go 版本的 TypeScript 可以非常有效地控制这种矛盾。
从团队去年 3 月给出的数据就可以看出，用 Go 改写的 TS 速率可提升 10 倍左右。
这会大大改善前端团队的日常体验。
过去一些团队为了速度或许会降低类型严格度，或者把类型检查从本地开发链路中移走。新版 TypeScript 稳定后，团队会更有动力启用严格类型配置，把类型错误检查前移到开发阶段。
生态影响
TypeScript 的底层改写，普通前端业务项目受益大概率是最大的，多数项目理论上只需要升级 TypeScript 版本，就能获得更快的 tsc 和更流畅的编辑器体验，但工具链开发者会面对更复杂的迁移。
很多工具依赖 TypeScript 的程序化 API，例如 typescript-eslint、ts-loader、API Extractor、代码生成器、文档工具、自定义 AST 分析等等。
官方已经说明 TypeScript 7.0 RC 阶段还没有稳定的程序化 API，稳定 API 至少要到 TypeScript 7.1。
因此，TS 生态暂时不会瞬间切换，会经历一段 TypeScript 6 与 TypeScript 7 并行的过渡期。
所以针对具体的业务项目，可以先增加 TypeScript 7 检查任务，观察差异。工具链项目则应保留 TypeScript 6 兼容路径。
对于依赖编译器 API 的项目，不能只看 tsc 是否变快，还要验证 AST、诊断、watch 模式、语言服务插件和第三方库是否稳定。
利好 AI 编程
AI 编程工具的质量，很大程度取决于它能否快速获得项目上下文。仅靠文本窗口，AI 容易生成看似合理但类型不匹配的代码。如果能结合 TypeScript 的完整语义信息，就能更准确理解类型、符号、导入路径、函数调用关系和错误位置。
TypeScript 官方也提到，AI 工具需要更大的语义信息窗口，并且对延迟要求更高。
Go 版本的语言服务如果持续稳定，会让 AI 编程工具更容易在大型仓库中执行跨文件分析、自动修复、重构建议、补全和代码审查。
此外，还值得注意的一点是，此次 TypeScript 是基于 LSP（语言服务器协议）构建的。
这里简单说一下语言服务器。
语言服务器是一种在后台独立运行的软件进程，专门负责分析源代码，并为代码编辑器或集成开发环境（IDE）提供语法检查、自动补全、跳转到定义等高级语言特性。LSP 则定义了编辑器或 IDE 与语言服务器之间的通信方式。
虽然 LSP 也是微软自家的技术，但之前 TypeScript 使用的一直是 tsserver API。
之所以没有严格兼容 LSP，是因为 tsserver 的出现早于 LSP，LSP 也正是受到了 tsserver 的启发，最终呈现出与编辑器的 UI 进程分离，在独立的进程中提供智能编程服务的效果。
TypeScript 7 转向 LSP 后，接口更标准。AI IDE、Agent、编辑器不必为 TypeScript 单独适配一套非标准协议，这会降低 AI 工具做跨语言支持的成本。
换成前端场景，就是 AI 能更快知道一个 React 组件真实 props 类型、更快定位某个 hook 的定义、更快找出某个 API client 的所有调用点、更快判断一次修改会不会破坏其他文件。
最后
现在可以直接通过 npm 安装最新版的 TypeScript：
npm install -D typescript@rc运行 tsx，看看是不是如官方所说速度能提升 10 倍之多。
> npx tsc --version
Version 7.0.1-rc
