TypeScript 的类型兼容性默认遵循结构子类型，也就是只看类型内部有哪些属性以及属性类型是否匹配，几乎不关心类型声明时的名称或来源。比如两个完全没有关系的接口只要成员一致，就可以互相赋值。这种设计让 TypeScript 能顺畅地描述大量动态 JavaScript 对象，但它并不是纯结构化的，在某些边界上 TypeScript 会显式地引入类似名义类型的判定，形成一种混合设计。理解这些非结构化机制出现的动机和具体行为，对避免误判类型安全、设计更严谨的 API 很有帮助。
一、结构兼容的基础：从接口赋值谈起
结构子类型的核心规则可以概括为：如果类型 S 的所有必需成员都能在类型 T 中找到兼容成员，那么 S 就可以赋值给 T。这个规则在变量赋值和函数参数传递时都适用。例如定义两个接口 Point2D 和 NamedPoint，它们拥有相同的 x、y 属性，尽管名字不同，赋值不会报错。
需要特别注意的是，TypeScript 对函数参数和对象字面量存在不同处理。对象字面量直接赋值给变量时会触发额外的属性检查，这是一种针对字面量的特殊规则，目的是避免手误多写属性。它并不是结构兼容的一部分，而是对结构化的一个补充限制。通过把字面量先赋给中间变量，再赋给目标类型，就可以绕过这个检查。
interface Point2D { x: number; y: number; }
interface NamedPoint { x: number; y: number; }
let p: Point2D = { x: 1, y: 2 };
let n: NamedPoint = p; // 结构兼容，通过
// 对象字面量额外属性检查
let q: Point2D = { x: 1, y: 2, z: 3 }; // 报错：z 不存在于 Point2D
从上面的代码可以看出，结构类型系统并不是完全“自由”的，它在某些场景下会通过额外规则约束类型的使用。对象字面量的额外属性检查是 TypeScript 中一个常见但容易被误解的行为，它让开发者在第一次书写字面量时就能得到更早的错误反馈，但不会影响后续变量之间的结构兼容。理解这一点，可以帮助区分哪些错误来自纯粹的结构判断，哪些来自额外的字面量检查。
二、非结构化机制：私有成员、unique symbol 与枚举
在结构化的世界里，两个类型只要形状一样就兼容。但 TypeScript 提供了几种机制，让类型之间即使形状完全相同，也会因为来源或标识不同而无法兼容。最典型的是类的私有成员和受保护成员。一个类如果含有 private 或 protected 成员，那么只有来自同一个类声明的实例才被认为是兼容的。两个声明完全相同 private 成员的类，不能互相赋值。
这种设计实际上是在结构类型系统中引入了名义类型的特征。它让类的身份变得重要，适合表示那些内部实现需要隐藏、不能随意替换的实体。比如两个不同模块定义的用户凭证类型，即使都只有一个 private 字段，也不能混用，从而增加了一层编译期的区分度。
class UserA {
private secret: string = 'a';
name: string = 'Alice';
}
class UserB {
private secret: string = 'b';
name: string = 'Bob';
}
let a: UserA = new UserA();
let b: UserB = new UserB();
// a = b; // 错误：UserA 和 UserB 的私有成员不兼容
另一个更灵活的非结构化工具是 unique symbol。它创建的类型不可重复，可以用作品牌类型的基础。品牌类型通常通过交叉类型把一个不可见的属性附加到基础类型上，从而在结构上区分两个语义不同的类型。例如把字符串包装成 UserId 和 OrderId，两者底层都是 string，但不能直接互相赋值。
declare const userIdBrand: unique symbol;
declare const orderIdBrand: unique symbol;
type UserId = string & { readonly [userIdBrand]: 'UserId' };
type OrderId = string & { readonly [orderIdBrand]: 'OrderId' };
function getUserId(id: UserId) { return id; }
const uid = 'u123' as UserId;
const oid = 'o456' as OrderId;
getUserId(uid);
// getUserId(oid); // 错误：OrderId 不能赋给 UserId
枚举也有类似名义类型的表现。不同枚举的成员即使值相同也不能互相赋值。例如 enum Color 和 enum Shape 都包含一个值为 1 的成员，但 Color.Red 不能赋给 Shape.Circle。
enum Color { Red = 1 }
enum Shape { Circle = 1 }
let c: Color = Color.Red;
let s: Shape = Shape.Circle;
// c = s; // 错误：Shape 不能赋给 Color
三、混合设计下的兼容性差异与工程实践
混合设计带来的第一个直接影响是函数参数兼容性的微妙变化。在严格函数类型检查开启时，函数参数逆变。但对于方法参数，TypeScript 仍然采用双变处理，这是出于对现有 JavaScript 类库的兼容。这种不一致可能导致一些类型漏洞，需要在实践中注意。例如一个接受窄参数的方法被赋给接受宽参数的函数类型时，可能不会报错，但调用时容易出现运行时错误。
品牌化类型是混合设计中最实用的部分之一。它允许开发者为基本类型附加语义标签，从而防止不同类型 ID、金额、度量单位之间的混淆。由于品牌属性是唯一的 symbol，任何其他类型都无法伪造，因此在编译期提供了很强的保证。常见的用法是定义品牌构造器和类型守卫，在运行时验证数据后返回品牌类型，之后所有 API 都可以信任这一类型。
declare const eurBrand: unique symbol;
type Euro = number & { readonly [eurBrand]: 'Euro' };
function toEuro(amount: number): Euro {
if (amount < 0) throw new Error('Negative amount');
return amount as Euro;
}
function formatEuro(amount: Euro): string {
return `€${amount.toFixed(2)}`;
}
const money = toEuro(100);
console.log(formatEuro(money));
// formatEuro(200); // 错误：number 不能赋给 Euro
不过品牌化类型也有代价：它会让一些依赖结构兼容的工具或测试变得麻烦。例如 mock 对象、序列化反序列化、从 API 返回的原始数据都需要显式断言或验证，否则结构上看起来一样的对象并不能通过类型检查。因此使用品牌类型时，应该搭配严格的入口验证函数，把脏数据在边界处转换成受信任的品牌类型，而不是到处使用 as 断言。
另一个容易踩坑的地方是 private 成员对类继承和接口实现的影响。一个类如果实现了某个接口，并在其中声明 private 成员，那么该 private 成员只属于这个类，不会成为接口的一部分。子类虽然可以继承父类的 private 成员，但只有父类与子类的实例在类型上兼容，不同子类之间的 private 成员归属不同会导致不兼容。这种基于声明来源的规则非常接近名义类型，理解它有助于定位一些难以解释的编译错误。
总体来看，TypeScript 的类型系统不是纯粹的结构化，也不是纯粹的名义化，而是在结构化基础上按需引入非结构化约束来解决身份区分、防止意外兼容和增强类型安全。掌握这些混合设计规则后，可以根据具体场景选择是否启用品牌类型、私有成员或枚举，在灵活性与安全性之间做出平衡。
TypeScript类型系统结构化类型名义类型修改时间：2026-10-07 01:31:37