我们的项目是一个前端项目, 有大约一百万行typescript代码,微软已经推出go 版本的typescript, 据说编译速度能提高10倍,本次就用我们的项目实战一把, 看看编译性能究竟有多少提高.
结论先行
**TypeScript 7.0 在本项目的 CLI 编译检查中展现出非常明确的性能收益：**外部 wall time (指程序 从开始执行到结束所花费的时间，包括了 CPU 时间和与 CPU 时间无关的时间)均值从 20.854s 降至 3.417s，降低 83.6%；TypeScript 内部 Total time(TypeScript 自己在 --extendedDiagnostics 里报告的总耗时) 均值从 19.326s 降至 2.879s，降低 85.1%；Check time(TypeScript 做类型检查花的时间) 均值从 15.267s 降至 1.940s，降低 87.3%。
换句话说，在这个约百万行级别的 TypeScript 代码库上，TS 7 把一次完整类型检查的等待时间从“十几到二十秒级”压缩到了“三秒级”。这类提升对本地开发、CI 快速反馈和大型项目日常重构都有直接价值。
| 核心指标 | TS 6.0.2 | TS 7.0 | 改善 |
|---|---|---|---|
| 外部 wall time 均值 | 20.854s | 3.417s | 降低 83.6%，约 6.10x |
| TypeScript Total time 均值 | 19.326s | 2.879s | 降低 85.1%，约 6.71x |
| Check time 均值 | 15.267s | 1.940s | 降低 87.3%，约 7.87x |
| Memory used 均值 | 850.624 MB | 638.801 MB | 降低 24.9% |
测试口径
为了尽量聚焦 TypeScript 编译器本身，本次主测试使用 tsc CLI，而不是完整生产打包。完整打包会混入资源生成、CSS/Sass、模块优化和压缩等因素，不适合作为编译器性能的唯一判断依据。
| 项目 | 说明 |
|---|---|
| 基线版本 | TypeScript 6.0.2 |
| 评估版本 | TypeScript 7.0.1（npm 标签） |
| 命令形态 | tsc -p <benchmark tsconfig> --noEmit --extendedDiagnostics --pretty false --skipLibCheck |
| 采样方式 | 每个版本 2 轮 warm-up，随后 7 轮正式样本 |
| 统计指标 | 外部 wall time、Total time、Check time、Parse time、Bind time、Memory used |
| 运行环境 | Windows，Intel Core i7-10750H，6 核 / 12 线程，79.76 GB 内存，Node.js v24.11.1 |
项目规模
| 指标 | 数值 |
|---|---|
| 仓库 TS/TSX 文件总数 | 2,754 |
| .ts 文件数 | 1,463 |
| .d.ts 文件数 | 1,291 |
| .tsx 文件数 | 0 |
| 源码文本总行数 | 1,137,460 |
| 非空行数 | 1,066,131 |
| TS/TSX 文件总大小 | 44,799,378 bytes（约 42.72 MiB） |
| 实际 tsc Program 文件数 | 1,317 |
| 实际 tsc Program TypeScript 行数 | 389,048 |
| 实际 tsc Program Definition 行数 | 63,453 |
| 实际 tsc Program Library 行数 | 53,396 |
性能数据
7 轮正式样本显示，TS 7 的提升不是偶然波动，而是稳定地体现在每一轮测量中。
| 轮次 | TS 6 wall(s) | TS 6 total(s) | TS 6 check(s) | TS 7 wall(s) | TS 7 total(s) | TS 7 check(s) |
|---|---|---|---|---|---|---|
| 1 | 19.583 | 17.570 | 14.120 | 3.258 | 2.781 | 1.877 |
| 2 | 22.454 | 20.810 | 16.370 | 3.133 | 2.636 | 1.747 |
| 3 | 20.916 | 19.600 | 14.810 | 2.899 | 2.453 | 1.665 |
| 4 | 20.378 | 18.860 | 15.230 | 3.676 | 3.085 | 2.139 |
| 5 | 21.400 | 20.120 | 16.160 | 3.634 | 3.161 | 2.306 |
| 6 | 21.240 | 19.660 | 15.410 | 3.746 | 3.165 | 2.080 |
| 7 | 20.008 | 18.660 | 14.770 | 3.576 | 2.872 | 1.763 |
| 指标 | TS 6.0.2 均值 | TS 7.0.1 均值 | 降低幅度 | 加速倍数 |
|---|---|---|---|---|
| 外部 wall time | 20.854s | 3.417s | -83.6% | 6.10x |
| TypeScript Total time | 19.326s | 2.879s | -85.1% | 6.71x |
| Check time | 15.267s | 1.940s | -87.3% | 7.87x |
| Parse time | 2.011s | 0.300s | -85.1% | 6.70x |
| Bind time | 1.109s | 0.072s | -93.5% | 15.40x |
| Memory used | 850.624 MB | 638.801 MB | -24.9% | 1.33x |
诊断规模对比
值得注意的是，TS 7 在内部统计口径上并不是简单减少工作量。Symbols、Types 和 Instantiations 的报告值更高，但整体耗时和内存占用反而显著下降，说明性能收益主要来自编译器实现和执行效率的提升。
| 指标 | TS 6.0.2 | TS 7.0.1 | 变化 |
|---|---|---|---|
| Files | 1,317 | 1,317 | 输入规模一致 |
| Identifiers | 727,100 | 727,100 | 源码标识符规模一致 |
| Symbols | 427,679 | 541,414 | +26.6% |
| Types | 163,096 | 330,466 | +102.6% |
| Instantiations | 85,040 | 146,138 | +71.8% |
| Memory used 均值 | 850.624 MB | 638.801 MB | -24.9% |
对开发体验的影响
- 本地类型检查反馈更短：一次检查从约 20.9s 降至约 3.4s，更接近可频繁执行的开发节奏。
- CI 中的类型检查阶段更有优化空间：即便只把 TypeScript 检查作为单独任务，TS 7 也能显著缩短等待时间。
- 大型重构更容易保持连续性：Check time 降低 87.3%，对类型密集代码库尤其有意义。
- 内存占用更友好：Memory used 均值降低约 211.8 MB，降低幅度 24.9%。
落地建议
从实测数据看，TS 7 已经值得在大型 TypeScript 项目中提前评估。建议采用渐进式路线：先把 TS 7 作为并行类型检查任务接入本地脚本或 CI，对比诊断结果和耗时；随后再评估现有构建工具、loader 和插件对 TS 7 编译器接口的支持情况。
如果团队的主要痛点是类型检查等待时间，可以优先把 TS 7 用在独立检查链路上，而不必立刻替换生产打包流程。这样既能尽早获得性能收益，也能让工具链升级保持可控。
总结
本次项目实测表明，TypeScript 7.0.1 对大型 TypeScript 代码库的 CLI 编译检查有非常积极的影响：主耗时指标普遍降低 83% 以上，Check time 接近 8 倍加速，内存均值降低约四分之一。对需要频繁类型检查的团队来说，TS 7 值得尽早进入评估清单。
