TypeScript作为JavaScript的超集，其核心价值在于静态类型检查。在类型系统中，类型兼容性决定了某个类型是否可以赋值给另一个类型。对于函数参数而言，严格的类型系统要求参数类型必须是逆变的，然而TypeScript在处理对象类型的方法参数时，却采用了双变性的检查机制。这种设计选择背后隐藏着一段关于数组协变的历史遗留问题，理解这一机制对于编写健壮的TypeScript代码至关重要。
协变与逆变：理解类型兼容性的基石
要深入理解双变性，首先需要厘清协变和逆变这两个核心概念。在类型系统中，协变指的是如果类型A是类型B的子类型，那么包含类型A的复合类型（比如数组Array<A>）也是包含类型B的复合类型（Array<B>）的子类型。简单来说，子类型关系在复合类型中得到了保留。这种机制非常符合直觉，比如如果Dog是Animal的子类，那么一群Dog自然也可以被看作是一群Animal。
与协变相反，逆变通常出现在函数参数的类型检查中。假设我们有一个函数类型(param: Animal) => void，如果另一个函数(param: Dog) => void想要赋值给它，是不安全的。因为目标函数期望能够接收任何Animal类型的参数，如果传入一个Cat，而实际执行的函数只能处理Dog，就会在运行时出错。因此，为了安全，函数参数的类型应该是逆变的，即只能将参数类型为父类的函数赋值给参数类型为子类的函数变量。在严格的函数式编程语言中，参数逆变是强制的，但TypeScript的情况更为复杂。
双变性的诞生：TypeScript的历史妥协
既然逆变是安全的，为什么TypeScript还要引入双变性？这主要源于早期JavaScript生态中数组的广泛使用。在JavaScript中，数组经常被用于协变操作，例如将Dog[]赋值给Animal[]。早期的TypeScript为了兼容这种常见的编码模式，允许数组进行协变。然而，数组拥有push等方法，如果允许Dog[]赋值给Animal[]，就意味着我们可以向这个原本是Dog数组的变量中push一个Cat，这在逻辑上是矛盾的，但在运行时却不会报错。
为了支持这种数组协变，TypeScript在检查对象类型（包括接口和类）的方法参数时，采取了双变性策略。双变性意味着编译器同时允许协变和逆变。当检查一个对象的方法是否兼容另一个对象的方法时，无论参数类型是子类还是父类，编译器都会放行。这种妥协使得数组的协变成为可能，但也打开了类型安全的一个缺口。以下代码展示了这种双变性的实际表现：
interface Animal {
name: string;
}
interface Dog extends Animal {
bark(): void;
}
interface Cat extends Animal {
meow(): void;
}
// 定义一个接收Animal的方法接口
interface AnimalShelter {
accept(animal: Animal): void;
}
// 实现一个只接收Dog的方法
class DogShelter implements AnimalShelter {
accept(dog: Dog): void {
console.log('接收了一只狗');
dog.bark();
}
}
// 双变性允许这种不安全的赋值
const shelter: AnimalShelter = new DogShelter();
// 运行时逻辑错误：将Cat传给了只能处理Dog的方法
// 由于Cat没有bark方法，调用会导致运行时错误
shelter.accept({ name: 'Tom', meow() { console.log('喵'); } });
在上述代码中，Dog和Cat都是Animal的子类。AnimalShelter接口期望一个接收Animal的方法，而DogShelter实现的方法接收的是更具体的Dog。按照逆变原则，DogShelter不能赋值给AnimalShelter，因为如果传入Cat，DogShelter无法处理。但由于双变性的存在，TypeScript编译器并没有报错，这就导致了运行时的逻辑错误。
双变性带来的隐患与严格模式的解决方案
双变性的存在使得TypeScript的类型系统在处理方法参数时显得不够严密。当方法参数被双向接受时，编译器对类型安全的保护就被削弱了。开发者可能会在不经意间将不兼容的类型传递给方法，从而引发难以调试的运行时错误。这种隐患在大型项目中尤为危险，因为类型的不匹配可能在跨越多个模块后才暴露出来，增加了代码维护的成本。
为了解决这一历史遗留问题，TypeScript在后续版本中引入了--strictFunctionTypes编译选项。当开启此选项后，编译器会对函数类型参数进行严格的逆变检查。但需要注意的是，这个严格检查仅适用于独立的函数声明和函数表达式，对于通过对象类型声明的方法（即使用method(): void语法的函数），依然保持双变性。这是为了向后兼容那些依赖方法双变性的现有代码库，避免升级TypeScript版本导致大量已有代码编译失败。
// 开启 strictFunctionTypes 后的行为对比
// 方法语法：保持双变性，不报错
interface MethodSyntax {
accept(animal: Animal): void;
}
// 函数属性语法：严格逆变，会报错
interface FunctionPropertySyntax {
accept: (animal: Animal) => void;
}
class DogShelterV2 {
accept = (dog: Dog): void => {
console.log('接收了一只狗');
};
}
// 报错：不能将类型Dog赋值给类型Animal的参数
// 类型 (dog: Dog) => void 不能赋值给类型 (animal: Animal) => void
const shelter2: FunctionPropertySyntax = new DogShelterV2();
因此，在现代TypeScript开发中，为了追求更高的类型安全性，推荐使用函数属性语法（如accept: (animal: Animal) => void）而不是方法语法（如accept(animal: Animal): void）。这样在开启严格函数类型检查后，编译器就能正确识别出不兼容的赋值操作并报错。理解双变性的历史背景和限制范围，有助于我们在编写复杂类型时做出更合理的设计决策，在兼容旧代码和追求类型安全之间找到平衡点。
TypeScript类型兼容性双变性修改时间：2026-08-20 09:23:31