这次更新真正的大动作只有一句话就够震撼编译器被重写成 Go 了。也正因为这个变化很多项目的构建速度会明显提升而且 TypeScript 终于开始支持原生多线程。换句话说这不是一次普通的版本更新而是 TypeScript 底层发动机被换掉了。下面直接拆开看它新在哪里哪些行为变了以及你今天怎么开始试用。如果你想实时跟进 React、JavaScript、TypeScript 以及更多前端技术动态也可以订阅我们的 Telegram 频道我们会持续更新最新内容和有意思的技术资讯。新地基Go 驱动的编译器过去TypeScript 一直是“自己编译自己”。也就是说TypeScript 的代码库本身用 TypeScript 写再编译成 JavaScript 运行。这种模式通常被称为 bootstrapped codebase。但到了 7.0这件事彻底变了。TypeScript 团队花了一年多时间把现有代码库系统性地迁移到了 Go。这个工程量不小但回报也非常直接性能提升相当明显。别被 “Beta” 这个标签吓到。对大多数使用场景来说它已经足够接近生产可用。核心类型检查逻辑在结构上和 6.0 保持一致。也就是说你不是在赌一套全新的语义也不是在试一个未经验证的实验性行为。TypeScript 7.0 已经跑过十年积累下来的测试并且已经在 Bloomberg、Figma、Google、Slack、Vercel、Notion 等公司的数百万行代码库上使用过。安装 Beta 很简单npm install -D typescript/native-previewbeta然后用tsgo替代tscnpx tsgo --version # Version 7.0.0-beta对 VS Code 用户来说TypeScript Native Preview 扩展可以把同样的性能提升带进编辑器里。自动导入、inlay hints、code lenses、跳转到源码定义等功能也都能享受到这套新底座带来的速度提升。并行化终于吃满多核了TypeScript 7.0 最大的架构收益之一是很多编译步骤现在可以并行执行。解析、类型检查、代码输出都可以跨文件并发进行。代码库越大这种收益越明显。以前 TypeScript 编译像是在一条窄路上排队通过。现在它终于开始利用多核 CPU把任务分发出去。类型检查也能并行类型检查是最难并行化的部分。原因很简单不同文件之间会共享类型信息而且还必须在一致的顺序中完成检查。稍微处理不好就可能出现不稳定、不一致甚至难以复现的问题。TypeScript 7.0 的做法是启动一个固定数量的 type-checker worker 池。每个 worker 都有自己对程序的视图然后协作完成检查。默认情况下它会使用 4 个 checker worker。你也可以用新的--checkers参数调整数量npx tsgo --checkers 8 # 适合大型代码库 npx tsgo --checkers 2 # 更适合资源有限的 CI 环境worker 越多构建可能越快但内存占用也会随之上升。所以这里不是越大越好而是要根据机器配置和项目规模找到平衡。项目引用构建也能并行TypeScript 7.0 现在还可以通过新的--builders参数同时构建多个项目。对 monorepo 来说这个变化非常关键。npx tsgo --checkers 4 --builders 4不过要注意一点--checkers和--builders是会相乘的。比如上面这个配置最多可能同时跑 16 个 type-checker。因此在性能和资源之间找到合适比例比盲目拉满更重要。需要单线程也可以有些场景下你可能并不想要并行。比如调试、性能对比或者在资源非常有限的环境中运行。这时可以使用npx tsgo --singleThreaded它会把 type-checker 限制为 1 个并强制解析和输出也在单线程中完成。这不是给日常开发准备的最快模式但对排查问题很有用。7.0 和 6.0 可以并排跑未来稳定版 TypeScript 7.0 最终会替换typescript包并继续使用tsc作为入口。但在迁移阶段为了降低切换成本团队提供了一个兼容方案npm install -D typescriptnpm:typescript/typescript6也可以在package.json里这样写{ devDependencies: { typescript: npm:typescript/typescript6^6.0.0 } }这样一来像typescript-eslint这种通过 peer dependency 引入typescript的工具仍然可以访问 6.0 语义与此同时你可以在项目里并行试用 7.0。这对大型项目迁移非常重要。因为真正痛苦的不是安装新版本而是生态工具链一起跟着变。破坏性变化和配置更新TypeScript 7.0 继承了 6.0 的新默认行为并且把 6.0 中已经废弃的配置升级成硬错误。如果你还没有迁移到 6.0现在最好先做这一步。这样会让 7.0 的迁移顺滑很多。这里最关键的一点是如果你的项目在 TypeScript 6.0 下可以干净编译并且启用了stableTypeOrdering同时没有设置ignoreDeprecations那么它在 TypeScript 7.0 下应该会产出一致结果。换句话说如果你的 6.0 构建已经“干净且诚实”没有靠废弃选项偷偷绕过去那你距离 7.0 已经不远了。TypeScript 团队也强烈建议先采用 6.0 作为过渡台阶。很多项目仍然需要先消化 6.0 的新行为再直接跳到 7.0。默认设置变了TypeScript 7.0 中一批默认配置发生了变化strict: true module: esnext target: 当前稳定 ECMAScript也就是 es2025 noUncheckedSideEffectImports: true libReplacement: false stableTypeOrdering: true并且永久启用不能关闭 rootDir: ./ types: []最容易让你踩坑的大概率是rootDir和types。如果rootDir出问题可以显式指定{ compilerOptions: { rootDir: ./src }, include: [./src] }如果types出问题也需要明确列出你真正需要的类型{ compilerOptions: { types: [node, jest] } }这类变化看起来不大但在老项目里很可能会一下子暴露很多隐性依赖。这些选项彻底没了下面这些配置在 6.0 中已经被废弃到了 7.0 会直接变成硬错误target: es5。你应该使用更现代的 target或者交给单独的转译工具处理。--downlevelIteration。它主要服务于 ES5现在已经不再适用。--moduleResolution node/node10。应该迁移到nodenext或bundler。--module amd | umd | systemjs | none。建议迁移到esnext再配合 bundler 使用。--baseUrl。需要把 paths 更新为相对于项目根目录的路径。--moduleResolution classic。应该使用nodenext或bundler。esModuleInterop: false和allowSyntheticDefaultImports: false。现在不再允许关闭。alwaysStrict: false。所有代码都会以 strict mode 处理。namespace 声明里的module关键字。应该改用namespace。imports 上的asserts关键字。应该改用with。outFile。应该交给 bundler 处理。这不是 TypeScript 突然变得激进而是在清理长期历史包袱。只是对老项目来说这一步确实会有疼痛感。JavaScript 文件支持被重做了TypeScript 7.0 重新审视了.js文件的分析方式。目标很明确让 JavaScript 文件的行为更接近 TypeScript 文件。早期的 JavaScript 支持主要围绕 JSDoc 注释和模式识别建立。当时它参考了 Closure 和 JSDoc 工具链里开发者正在使用的写法。这个设计很务实也确实帮助了很多松散类型的 JS 代码库。但多年下来它积累了大量特殊情况并且和.ts文件的分析逻辑越来越不一致。这次迁移到 Go正好给团队提供了一个清理技术债的机会。于是JS 和 TS 的分析管线开始被重新对齐。需要注意的变化包括在需要类型的位置使用值时要改成typeof someValue。enum被移除应该改用typedef on (typeof YourEnum)[keyof typeof YourEnum]单独的?类型不再保留特殊含义应该使用any。函数上的class不再推荐应该改成真正的 class 声明。后缀!不再需要直接使用T。紧挨着标识符的typedef不再被接受必须写在 tag 本身内部。Closure 风格的函数类型语法比如function(string): void应该改成(s: string) void此外一些模式也不再享受特殊处理比如给this起别名或者重新赋值整个函数的 prototype。简单说TypeScript 7.0 对 JavaScript 文件更严格也更一致。它不再愿意背那么多历史兼容包袱。编辑器体验也变快了7.0 的性能提升并不只体现在命令行里。VS Code 的 TypeScript Native Preview 扩展已经逐渐成熟现在支持自动导入 可展开的 hover 提示 inlay hints code lenses 跳转到源码定义 JSX linked editing 和标签补全。它基于 Language Server Protocol 构建因此不只服务于 VS Code也可以在多数编辑器中工作。同时它会继续使用你现有的tsconfig设置把 CLI 里的性能提升带进日常编辑体验。当然还有一些功能仍在追赶中。但它已经足够快、足够稳定也已经可以支撑很多日常 TypeScript 开发工作。最后TypeScript 7.0 Beta 最重要的地方不是多了几个漂亮的新语法。它真正改变的是底座。编译器从 TypeScript/JavaScript 迁移到 Go意味着 TypeScript 开始真正拥抱原生性能、多线程和更现代的工程架构。对小项目来说你可能只是觉得“快了一点”。但对大型代码库、monorepo、CI 构建和编辑器响应来说这会是非常实际的变化。当然代价也很明确。老配置会被清理历史行为会被收紧JavaScript 文件分析会更一致也更严格。那些长期靠旧选项和隐式行为维持的项目迁移时大概率会被迫面对技术债。但这未必是坏事。TypeScript 7.0 像是在说过去十几年积累下来的包袱该还的终于要还了。如果你的项目已经在 TypeScript 6.0 下干净运行那么试用 7.0 的门槛并不高。先安装typescript/native-previewbeta用tsgo跑一遍再看看构建速度和编辑器体验的变化。这一次TypeScript 不是只在类型系统上继续雕花。它是在换发动机。最后精通 React 面试从零到中高级(针对面试回答)CSS终极指南Vue 设计模式实战指南20个前端开发者必备的响应式布局深入React:从基础到最佳实践完整攻略python 技巧精讲React Hook 深入浅出CSS技巧与案例详解vue2与vue3技巧合集