在使用TypeScript的过程中，你大概率遇到过这样的困惑：两个完全没有继承关系的类型，为什么能互相赋值？而某些看起来结构几乎一样的类型，编译器却报了类型不兼容的错误。这些现象背后，其实是TypeScript的类型兼容性判断规则在发挥作用。理解这套规则，是从会用TypeScript到真正掌握TypeScript的关键一步。
结构化类型系统：一切兼容性判断的基础
TypeScript采用的是结构化类型系统，也就是说，判断两个类型是否兼容，看的不是它们的声明名字，而是它们的实际结构。只要类型A拥有类型B所需要的全部属性和方法，A就可以赋值给B，无论A是否显式声明过要实现B。
与结构化类型相对的是名义类型系统，Java和C#是典型代表。在Java中，即使两个类的字段完全相同，只要没有继承或实现关系，它们之间就不能互相赋值。下面用一个对比来帮助理解：
// 结构化类型的典型例子
interface Point {
x: number;
y: number;
}
const p = { x: 1, y: 2, z: 3 }; // 额外多了z属性
const point: Point = p; // 完全合法，因为p包含了Point需要的所有属性注意这里有一个细节：如果把对象字面量直接赋值给变量，TypeScript会进行 excess property checking，也就是多余属性检查：
interface Point {
x: number;
y: number;
}
// 直接赋值字面量会报错
const point: Point = { x: 1, y: 2, z: 3 }; // 错误：z不存在于Point中
// 先赋值给中间变量再赋值就能通过
const tmp = { x: 1, y: 2, z: 3 };
const point2: Point = tmp; // 正常通过这说明多余属性检查只针对字面量的新鲜度（freshness）生效，经过一次变量赋值后，新鲜性消失，检查就不再触发。这个特性经常被用来故意绕过检查，但它本身是一种防止拼写错误的保护机制，不建议滥用。
协变与逆变：函数类型的兼容性核心
函数类型的兼容性判断是最容易出错的部分，因为它涉及到协变和逆变两个方向。TypeScript的规则可以概括为：参数是逆变的，返回值是协变的。
返回值协变很好理解：如果函数f的返回值类型是函数g返回值类型的子类型，那么f可以赋值给g类型的位置。因为调用方期望拿到g的返回值，而f返回的东西只会更具体，天然满足期望。
// 返回值协变
let a: () => { x: number; y: number } = () => ({ x: 1, y: 2 });
let b: () => { x: number } = a; // 合法：返回值多给点没关系参数逆变则相反：函数f的参数类型必须是函数g参数类型的父类型（更宽泛），f才能赋值给g。因为调用方会按g的签名传入参数，f必须能处理g能收到的一切参数，所以f的参数范围不能更窄。
// 参数逆变
let f: (value: { x: number; y: number }) => void =
(value) => { console.log(value.x + value.y); };
let g: (value: { x: number }) => void = f; // 报错吗？
// 实际上报错：f要求参数必须有y，而g的调用者可能只传x不过在实践中你会发现，TypeScript在很多版本里对方法参数采用了双向协变的宽松策略，也就是协变和逆变都允许。这是历史原因造成的：早期为了兼容Array等内置类型的写法，strictFunctionTypes开关没有开启时，函数参数位置就是双向协变的。开启strictFunctionTypes之后，通过函数声明的类型标注才严格逆变，而接口中的方法仍然保持双向协变。这也是为什么推荐始终开启严格模式的原因之一。
不同类型的兼容性规则细节
基础类型与枚举
基础类型的兼容规则比较直接：number兼容number，string兼容string，任何类型都能赋值给unknown，never可以赋值给任何类型。但枚举值得特别注意：数字枚举和number是双向兼容的，而不同枚举之间即使成员值相同也不兼容。
enum Status { Active, Inactive }
enum Color { Red, Green }
let n: number = Status.Active; // 合法
let s: Status = 1; // 合法
let c: Color = Status.Active; // 报错：枚举之间不兼容类与泛型
类的兼容性比较只看实例成员，静态成员和构造函数不参与比较。私有成员和保护成员有特殊规则：如果两个类中有相同名称的private成员，它们必须来自同一个声明才能兼容，这实际上让带有私有成员的类具备了名义类型的特点。
class Animal {
private name: string;
constructor(name: string) { this.name = name; }
}
class Employee {
private name: string;
constructor(name: string) { this.name = name; }
}
let a: Animal = new Employee("Tom"); // 报错：name来自不同声明泛型的兼容性判断基于类型实例化后的结构。只有当类型参数被实际使用时才会影响兼容性，如果类型参数只出现在声明中而没被用到，它对结构没有影响，两个不同参数的泛型依然兼容。
interface Empty<T> {}
let x: Empty<number> = {} as Empty<string>; // 合法：T没被用到
interface NotEmpty<T> {
data: T;
}
let y: NotEmpty<number> = {} as NotEmpty<string>; // 报错：data类型不同常见报错排查与最佳实践
掌握了规则之后，遇到兼容性报错时可以按固定思路排查。第一步确认赋值方向是否搞反，TypeScript检查的是源类型到目标类型的兼容，方向反了自然失败。第二步检查可选属性，带可选属性的类型不能赋值给要求必选属性的目标。第三步注意数组和联合类型，Array<Dog>不能赋值给Array<Animal>在启用严格检查时会被拦截，因为数组的写入操作会破坏类型安全。
还有一个高频问题是never和unknown的混淆。unknown是所有类型的父类型，任何值都能赋值给它，但使用前必须收窄；never是最底层类型，只能被赋值，不能赋出。这两个类型配合起来可以实现条件类型中的排除逻辑：
type NonNullable<T> = T extends null | undefined ? never : T; // 利用never在联合类型中被吸收的特性做过滤 type ExcludeKeys = "a" | "b" | never; // 等同于 "a" | "b"
实践中建议：始终开启strict全家桶，让函数参数严格逆变；避免用any绕过检查，需要逃逸时优先用unknown加类型守卫；设计接口时保持结构最小化，只声明真正需要的属性，这样兼容性判断的结果才符合直觉。结构化类型给了我们灵活的组合能力，但灵活的代价就是错误可能藏得更深，理解判断规则正是为了在灵活和安全之间找到平衡点。
TypeScript子类型兼容性结构化类型修改时间：2026-09-09 01:30:46