TypeScript 要换芯了，6.0 竟是旧编译器的最后一舞
微软 TypeScript 团队近日宣布typescript6.0 已在 npm 上可用。这一版在路线图上的位置很特殊，官方明确将其定位为基于现有 JavaScript 技术栈实现的编译器的最后一次大版本迭代。团队正用 Go 重写编译器与语言服务，新版本将支撑未来的 TypeScript 7.0 及之后版本，并利用原生性能与多线程共享内存。
对日常写业务代码的开发者来说，6.0 既是可立刻升级的正式版，也是面向 7.0 的排练场。官方称 7.0 已非常接近完成，VS Code 与 npm 上均可试用原生预览。若能顺利升到 6.0，团队建议同时尝试 7.0 预览，以便提前暴露工程上的问题。
安装方式与往常一样。
npm install -D typescript去年起微软已多次公开 Go 版编译器计划，近期说明见 TypeScript 官方博客索引。下文按"报道视角"整理升级价值、新特性要点，以及可能踩坑的破坏性变更与迁移提示。
6.0 在整条链路里扮演什么角色
5.9 与未来的 7.0 之间，6.0 主要做两件事。一是把语言与编译器行为尽量向 7.0 对齐，减少将来一次性换引擎时的撕裂感。二是在此基础上仍交付一批独立有价值的功能与修正，而不只是"为对齐而对齐"。
自 6.0 beta、RC 以来，正式版相对预览版还有几处值得注意的收紧，多数也是为了与 7.0 一致。包括在泛型调用里对函数表达式（尤其泛型 JSX）的类型检查更严，可能多报一些问题，部分泛型调用需要手写类型实参。import 断言语法在动态import()上的弃用范围也扩大了。DOM 类型则跟进最新 Web 标准，含对 Temporal 相关声明的调整。
类型推断里对无this方法更友好
这是一个典型"修边角但真能省时间"的改动。过去在对象字面量里，若produce、consume这类成员用方法简写而参数又没写类型，推断顺序和"上下文敏感函数"规则叠在一起时，consume里参数有时会被推断成unknown，而箭头函数写法却正常。根因之一是方法形参隐含this，类型系统曾一律把这类函数当成上下文敏感，即使函数体根本没用到this。
6.0 的规则是，若函数体内从未真正使用this，就不再按上下文敏感那套低优先级处理，推断会更符合直觉。对大量写对象字面量回调的代码库，升级后有望少写一批显式注解。实现归功于社区贡献者 Mateusz Burzyński。
Node 子路径导入支持#/前缀
Node 的package.json里imports字段允许包内用#开头的别名，避免深相对路径。此前规范要求#后面必须还有一段（例如#root/），和很多人习惯的@/式别名心智不完全一致。较新的 Node.js 20 已支持以#/直接映射（例如"#/*": "./dist/*"）。TypeScript 在--moduleResolution为nodenext或bundler时已跟进。相关工作由 magic-akari 等人推动。
bundler解析可以和commonjs模块目标一起用
以前--moduleResolution bundler只能和esnext或preserve等模块格式搭配。随着旧的node10式解析被弃用，不少项目需要一条现实的升级路径。6.0 允许把bundler解析与--module commonjs组合使用。长期仍建议按项目形态规划，要么走向preserve加bundler，要么走向nodenext，取决于你是打包 Web、跑Bun还是直出 Node。
--stableTypeOrdering是给对比测试用的开关
这是为 6.0 与 7.0 并行对照专门准备的选项。TypeScript 内部会给类型分配 ID，联合类型字面量顺序、声明文件里展示顺序等会受程序里声明先后影响。7.0 引入并行检查后，必须用确定性排序避免同一份代码在不同次检查里产出不一致的.d.ts或偶发错误。6.0 的--stableTypeOrdering让排序行为贴近 7.0，方便你做 diff 和排查。
代价是类型检查可能明显变慢，官方提到极端情况下可达约四分之一量级的额外耗时，因此不建议作为日常默认配置。若打开后出现新错误，往往是此前推断"碰巧"依赖了旧顺序，可通过显式类型实参或变量注解收紧。该标志只用于迁移期诊断，不是长期功能。
标准库与类型方面
target与lib新增es2025。ES2025 本身没有新语法，但会带上诸如RegExp.escape等内置 API 类型，并把部分原先在esnext的声明收进es2025（例如Promise.try、若干Iterator与Set方法）。- Temporal 已到 stage 4，6.0 内置类型。可通过
esnext或更细的esnext.temporal使用。运行时是否可用仍取决于引擎。 Map与WeakMap的getOrInsert、getOrInsertComputed随 ECMAScript upsert 提案进入esnextlib。RegExp.escape随es2025lib 可用。dom这一档 lib 现已内置原先dom.iterable与dom.asynciterable的内容，现代浏览器场景下多数项目可只写"dom"，少一层配置心智负担。
破坏性变更与默认值，为什么和你有关
官方把 6.0 定义为过渡版，与 5.9 仍保持 API 兼容，但默认行为与弃用项会动到大量存量项目。可在tsconfig里暂时写"ignoreDeprecations": "6.0"压制弃用提示，但 7.0 将移除这些兼容，迟早要直面。
几个最可能影响升级体验的默认变化如下。
strict默认为true。以前靠隐式非严格的项目需要显式写"strict": false才能维持旧行为。
module默认esnext，target默认跟到当前支持的年份规格（文中写作现阶段为es2025），整体假设是面向常青运行时。
noUncheckedSideEffectImports默认开启，纯副作用导入更容易因笔误报错。
libReplacement默认关闭，减轻 watch 模式下的解析与监视负担；新空项目里通常也感知不强。
rootDir默认变为配置文件所在目录（.），不再自动从所有输入文件推公共根。若你过去依赖推断且输出目录里突然出现多一层src，需要显式设"rootDir": "./src"等。
types默认改为空数组[]，不再自动把node_modules/@types下所有包全灌进全局。这是构建提速的关键之一，官方称不少项目仅这一项就有约两成到五成的编译时间改善。代价是若你习惯"不写types也能全局拿到 Node、Jest 等全局"，升级后会大量报找不到process、describe等，需要在compilerOptions.types里显式列出node、jest等。若必须完全恢复旧行为，可设"types": ["*"]，但不推荐作为长期方案。
其他已弃用或移除项包括：target: es5、--downlevelIteration、--moduleResolution node（node10）、amd/umd/systemjs/none等模块格式、--baseUrl作为解析根、moduleResolution: classic、esModuleInterop与allowSyntheticDefaultImports设为false、alwaysStrict为false、--outFile、命名空间用旧关键字module写的语法、import assertions 的asserts写法（应改用with）、no-default-lib指令等。命令行在已有tsconfig.json的目录里若仍传文件列表，6.0 会报错，需加--ignoreConfig才能恢复"只编单个文件、忽略配置"的旧习惯。
对团队与编辑的实操建议
若你负责维护中大型仓库，比较稳妥的顺序是，先在分支上升级 6.0，打开完整类型检查与 CI，按报错逐项补types、调整rootDir与路径映射，再视需要跑社区里的迁移辅助工具（文中提到的实验性 ts5to6 可处理部分baseUrl与rootDir相关调整）。有声明文件快照测试或依赖联合类型顺序的库作者，可用--stableTypeOrdering与 7.0 预览做对照，避免把顺序噪声当成逻辑 bug。
对只关心应用交付的团队，优先确认 Node 版本、测试全局与构建脚本是否在升级后仍能通过，再安排一次集中处理弃用警告，避免卡在 7.0 正式落地的前一刻。
小结
TypeScript 6.0 在功能上仍有 Temporal、RegExp.escape、getOrInsert、子路径#/等可感知的更新，但舆论与工程上的主轴很清楚，就是为 Go 重写、并行类型检查与更确定的编译器行为做准备。微软预计 7.0 在数月内趋于稳定，并已在内外部大型代码库上验证。对中文技术社区而言，这一版最值得传播的不只是特性列表，而是"默认更严、类型包显式化、旧模块体系退场"三条主线，它们会共同决定接下来一两年前端与 Node 工具链的升级节奏。