在TypeScript中，当我们实例化一个泛型类时，类型参数的传递并不是简单的赋值操作，它背后涉及一套基于结构兼容性的规则。很多开发者可能遇到这样的困惑：两个看似不同的类型为什么能够互相赋值？泛型类的实例为什么可以赋给另一个不同泛型参数的变量？这篇文章将深入探讨这些现象背后的原理，从类型兼容性的角度拆解泛型类实例化时的类型参数传递过程。
结构类型系统与类型兼容性的基础
TypeScript采用的是结构类型系统，也就是说，类型的兼容性取决于其成员的结构，而不是类型的名称或来源。两个类型只要拥有相同或兼容的成员，它们就可以互相赋值。比如下面两个接口，虽然名称不同，但结构完全一致，因此Cat类型的变量可以赋给Dog类型的变量。
interface Cat {
name: string;
age: number;
}
interface Dog {
name: string;
age: number;
}
let cat: Cat = { name: 'mimi', age: 2 };
let dog: Dog = cat; // 兼容，因为结构相同
这种兼容性是递归的，对于对象属性、函数参数、返回值等都会检查结构。但需要注意的是，当成员类型本身是泛型时，兼容性判断就会变得更加复杂，因为泛型参数的不同会导致成员结构的差异。
泛型类实例化时的类型参数传递规则
泛型类在实例化时可以显式指定类型参数，也可以让编译器根据传入的值进行推断。例如定义一个简单的Box类：
class Box<T> {
value: T;
constructor(value: T) {
this.value = value;
}
}
let stringBox = new Box<string>('hello');
let numberBox = new Box(42); // 类型推断为 Box<number>
在上面的代码中，stringBox的类型是Box<string>，numberBox的类型是Box<number>。这两个类型是否兼容呢？答案是不兼容，因为Box<string>的value属性类型是string，而Box<number>的value属性类型是number，string和number之间没有兼容关系，所以结构不匹配。
但如果类型参数之间存在兼容关系，比如Box<string>和Box<unknown>，情况就不同了。由于string可以赋值给unknown，那么Box<string>实例的value属性（string类型）就可以赋给Box<unknown>实例的value属性（unknown类型），因此Box<string>可以被视为Box<unknown>的子类型。这种兼容性是基于属性类型的方向，称为协变。
显式传递类型参数时，编译器会严格按照指定的类型生成实例类型，但并不会检查该类型参数是否“合理”，只会影响后续类型运算。而类型推断则根据构造器参数、上下文等自动推导，有时推断出的类型会比显式指定更具体或更宽泛，这也会影响后续的赋值兼容性。
协变、逆变与双向协变在泛型类中的体现
类型兼容性不仅取决于属性，还取决于方法。当泛型参数出现在方法参数位置时，兼容性方向可能会反转。我们来看一个Handler的例子：
class Handler<T> {
handle(arg: T): void {
console.log(arg);
}
}
let stringHandler = new Handler<string>();
let unknownHandler = new Handler<unknown>();
现在的问题是，stringHandler能赋给unknownHandler吗？从方法参数来看，Handler<unknown>的handle方法接受unknown类型参数，而Handler<string>的handle方法接受string类型参数。如果我们将stringHandler赋给unknownHandler变量，那么调用unknownHandler.handle(123)时，实际执行的是stringHandler.handle(123)，但stringHandler.handle期望参数是string，传入number会导致类型不安全。因此，在严格函数类型检查下（开启strictFunctionTypes），方法参数是逆变的，即Handler<unknown>可以赋给Handler<string>，而反过来不行。但TypeScript默认对方法（非函数属性）采用双向协变，所以两种赋值可能都被允许。这一点经常给开发者带来困惑。
为什么会有双向协变？因为TypeScript为了兼容JavaScript生态中的常见模式（如事件处理、回调等），对方法参数做了放宽处理。但如果使用readonly属性或函数类型属性（如handle: (arg: T) => void），则会严格执行逆变规则。理解这些差异对于写出类型安全的泛型类至关重要。
此外，当泛型参数同时出现在属性和方法参数中时，整个类的变型方向取决于所有成员的综合结果。例如一个泛型类既有value: T属性，又有setValue(arg: T)方法，那么它既不是简单的协变也不是简单的逆变，而是不变（invariant），只有类型参数完全相同时才兼容。这也是为什么大多数容器类（如Array）在类型参数上是不变的。
实际开发中的技巧与常见陷阱
理解这些规则后，我们可以在实际编码中更好地利用类型兼容性。例如，当你有一个泛型仓库类Repository<T>，其中T表示实体类型，如果实体之间存在继承关系，那么Repository<子类>可以赋给Repository<父类>吗？这取决于T在类中的使用方式。如果T只出现在返回值或只读属性中，那么可以享受协变带来的灵活性；但如果T出现在方法参数或可变属性中，就需要特别小心。
一个常见的陷阱是误以为Array<Cat>可以赋给Array<Animal>，从而将猫数组当作动物数组使用。实际上，由于数组的push方法接受T类型的参数，数组在T上是不变的。所以let animals: Animal[] = cats;会报错，除非使用ReadonlyArray<Cat>来获得协变能力。这是TypeScript为了阻止通过push方法将狗添加到猫数组中而设置的保护。
另一个技巧是利用类型推断减少显式类型参数，让编译器根据上下文推断，这样往往能回避一些手动指定引发的兼容性问题。同时，合理使用泛型约束（extends）可以缩小类型参数的范围，使结构兼容性更加可控。例如class Container<T extends object>保证了T至少是对象，从而在内部访问value成员时不会因原始类型而出现意外。
最后要提醒的是，开启strictFunctionTypes（属于strict模式的一部分）可以让函数参数类型检查更严格，避免一些潜在的运行时错误，但也会改变某些既有代码的赋值行为。在升级TypeScript版本或调整编译器选项时，需要重新审视泛型类的类型参数传递逻辑，确保代码的类型安全与业务逻辑一致。
总的来说，泛型类实例化时的类型参数传递不是孤立的语法现象，而是深度绑定了TypeScript的结构类型系统和变型规则。通过理解协变、逆变和不变，我们能够更准确地预测类型检查结果，写出更健壮的泛型代码。
TypeScript泛型类类型兼容性修改时间：2026-09-25 10:01:10