一、前言：我最初只当它是一次版本号升级

手头这个项目跑了多年。今年 TS6 稳定版一发布就升了上去，编译一次 45 秒，我早就习惯了。TS7 发布那天技术群都在转公告。我扫了一眼，心想：又来了估计就是加几个语法糖，顺手把版本号一改就完事。

结果 tsc 一跑，满屏报错。Cannot find name 'process'import 断言全部报错、namespace 写法也不认了。我第一反应是装漏了 @types，装了一圈发现没用，翻文档才反应过来：这不是小迭代。是 TS 史上第一次底层完全重写，内部代号 Project Corsa，用 Go 重写了整个编译器。其实，编译和类型检查的速度提高在 **9 倍** 这个区间。编辑器响应是质变级别的，还带上了多线程并行能力。

TS7 刚发布。全网实战落地、踩坑、迁移的内容还是稀缺的，正好是窗口期。身边中高级前端、做工程化的朋友，还有被编译卡顿折磨的团队。问我的都是同一个问题：这次到底值不值得动。我没法替所有人回答，只能把手头这个项目怎么升的、哪些坑是真实的、哪些提高是实测出来的，原原本本讲一遍。

这篇从五个新特性怎么上手开始。到 TS6 vs TS7 的性能实测数据，再到完整迁移方案和一份避坑清单，全是我这次升级实际走下来的。

二、TS7 主要定位 & 版本差异

前我花了两天把两个版本的关系捋清楚。

TS6. 是 JS 编译器终版。属于过渡性的规范更新，做的都是语法和配置层面的微调。它在 TS5 的基础上修修补补，没有动底层。

TS7. 是 Go 原生重构，这是一次架构级革命。性能质变来自架构本身，而不是哪一处调整。它最大的底气是并行编译能力：编译器不再是一个单线程的 JS 程序，而是一个能吃满多核的 Go 程序。

前我最关心一句话：语法语义 **100% 兼容 TS6**。无语法断裂，升级成本低、收益极高。这里有个容易绕晕的点，我踩过：% 兼容指的是语法语义层面你写出来的 TS 代码在 TS7 里语义不变；但默认配置和部分规范是收紧的，这就是为什么升级后会出现报错。不是语法断了是默认值变了。后面第三、六章会展开，

TS7 的主要更新可以分成五类：

• 底层架构升级
• 性能调整
• 语法规范收紧
• 工程配置变更
• 编辑器体验改善

三、快速上手：TS7 安装 & 全新 tsconfig 默认配置

安装很简单。两条命令，项目级和全局各一条：

npm i -D typescript@latest # 项目级
npm i -g typescript@latest # 全局，临时体验用

装完我第一件事是跑 tsc --initTS7 生成的全新默认配置和 TS6 差异不小。我当时看了一眼生成的 tsconfig。第一反应是“这配置怎么这么干净”，接下来才发现坑在哪儿。不过，

{
"compilerOptions": {
"target": "ES2022","module": "NodeNext","alwaysStrict": true,"types":,"noUncheckedSideEffectImports": true
}
}

三个主要默认变更。每个都会影响现有项目：

1. alwaysStrict 默认 true. TS6 默认 false. 包含 with,八进制等非严格语法会直接报错。
2. types 默认空数组. TS6 会自动加载所有 @types/*. 升级后全局类型（如 #process#,#jest#) 一夜之间全丢。
3. noUncheckedSideEffectImports 默认开启. 副作用导入（) 找不到模块声明即报错。

环境兼容检查：

`>=10` 才支持.

四、重磅主要：TS7 底层架构质变

This section explains *** rewrite was inevitable.

为什么必须重写：三大痛点

• 30 秒;
• 4 GB 内存;

I’s project on TS6 冷启动需要 **45 秒**，每次全量编译都要等杯水凉下来。不过，

Go 重构的三个主要优势

三大并行能力

•  类型检查按文件切片并行推进;
•  -b 建立多个 project reference 时并行;

  Oops I see re's a mistake;we need correct HTML. Let's rewrite this section properly.