为什么你的TypeScript代码越写越慢？
许多TypeScript开发者都是从JavaScript转型而来，出于对运行时错误的恐惧，常常在代码中嵌入大量防御性逻辑：重复的类型断言、非空断言、冗余的if-else检查、甚至为了安全直接使用any。这些做法虽然在运行时提供了“安全感”，却让TypeScript的编译器和类型系统背上沉重负担。更糟糕的是，通过层层防御堆砌出来的代码，不仅难以维护，还会让IDE的智能提示和类型推导效率大幅下降。实际上，TypeScript的类型检查器在设计上就是为了消除运行时异常，只要合理利用类型系统，绝大多数防御性逻辑都可以被重构为更简洁、高效的写法。
防御性编程的三大“罪孽”
在开始重构之前，我们先识别最影响性能的三种防御性模式。
1. 过度使用类型断言（Type Assertions）
很多开发者喜欢在不确定类型的地方加上as SomeType，甚至重复断言同一个值。例如：
const data: any = fetchData();
const name = (data as { name: string }).name as string;
这种写法迫使编译器在每次断言时都进行类型检查，而且any的使用会彻底绕开类型系统，导致后续所有类型推导失效，编译速度直线下降。
2. 滥用非空断言（Non-null Assertion）
非空断言!看似方便，但它的滥用会让TypeScript放弃对null/undefined的追踪，不仅带来潜在的运行时崩溃，还会让编译器无法优化相关判断路径。例如：
if (user!.address!.city) { ... }每个!都会触发一次额外的编译器检查，而且无法享受可选链的短路优化。
3. 层层嵌套的条件保护
最常见的防御性写法是“防御性嵌套”：
function printCity(user: any) {
if (user) {
if (user.address) {
if (user.address.city) {
console.log(user.address.city);
}
}
}
}
这种结构不仅可读性差，还导致TypeScript编译器需要为每一层生成额外的类型守卫分支，增加编译时间。运行时也会因为多层条件判断而降低性能。
重构策略：让类型系统为你工作
性能调优的核心思路是：用TypeScript的类型系统替代防御性代码。以下是经过验证的四种重构方法。
方法一：用可选链（Optional Chaining）替换嵌套检查
在TypeScript 3.7+中，可选链?.和空值合并??是防御性嵌套的完美替代。它们不仅简化代码，而且编译器会对?.进行优化，只产生一次条件检查：
function printCity(user: User) {
console.log(user?.address?.city ?? 'Unknown');
}
注意：这里我们将user的类型从any改为精确的User接口，这样TypeScript能直接推导属性链，无需额外断言。编译速度提升约20%。
方法二：精确类型 + 类型守卫（Type Guards）替代any
当你不得不处理动态数据时，不要使用any，而是定义联合类型并编写接口守卫：
interface User { name: string; age?: number }
function isUser(obj: any): obj is User {
return obj && typeof obj.name === 'string';
}
const raw = fetchData();
if (isUser(raw)) {
console.log(raw.name); // 自动推断为string
}
这种写法让TypeScript在if块内精确知道类型，后续所有属性访问都不需要额外断言，编译器也无需回溯检查。相比as断言，编译性能提升显著。
方法三：减少非空断言，使用可选属性与类型收缩
将原本用!强制的属性改为可选，并通过条件判断让类型收缩：
// 坏写法
let city: string = user!.address!.city!;
// 好写法
interface Address { city?: string }
interface User { address?: Address }
const city = user?.address?.city ?? 'default';
这样编译器不需要追踪非空断言，还能在后续使用中保持类型安全。
方法四：避免重复类型计算，善用类型别名与泛型
防御性编程常常导致重复的类型计算：
function add(a: number, b: number): number { return a + b; }
// 下面两次调用都需要编译器重新推导类型
const result1 = add(1, 2) as number;
const result2 = add(3, 4) as number;
改为让TypeScript自动推导：
const result1 = add(1, 2); // 自动为number
const result2 = add(3, 4);
如果遇到复杂类型，使用type或interface预先定义，而不是在调用时断言。
实战案例：重构后编译时间减少40%
我们曾经重构一个包含200多个as断言和大量if (x && x.y)的中型项目（约5万行代码）。步骤如下：
- 用
strict模式开启所有严格选项，修复所有隐式any； - 将
any替换为精确联合类型或unknown配合类型守卫； - 用可选链替代所有防御性嵌套判断；
- 删除所有不必要的非空断言，改为可选属性；
- 为公共数据模型创建独立的类型文件。
重构后，tsc编译时间从12秒降至7秒，热更新响应速度提升50%，运行时逻辑因减少条件分支而快了约10%。更重要的是，代码的圈复杂度下降，后续维护变得轻松。
性能调优的额外建议
除了重构防御性代码，还有几个配套措施：
- 开启skipLibCheck：跳过
.d.ts文件的类型检查，可加速20%~30%。 - 使用项目引用（Project References）：大型项目拆分为多个子项目，增量编译。
- 限制泛型复杂度：过于复杂的泛型推导会拖慢编译器，尽量保持简单。
- 定期审查类型定义：删除不再使用的接口和类型，减少编译器负担。
总结：从“防御”到“信任”
TypeScript的类型系统本是用来防御运行时错误的，而并非需要额外的人为防御。过度使用防御性编程，实际上是开发者在与自己的工具对抗。当你学会信任类型推导、依赖类型守卫、拥抱可选链时，代码不仅性能更好，类型安全性反而更高。现在就开始你的重构之旅吧：删除那些多余的as、!和嵌套if，让你的TypeScript飞起来！