TypeScript 结构化类型与函数兼容性
解释 TypeScript 为什么按成员形状判断兼容性，以及该规则对对象、回调参数和函数赋值的影响。
[!info] related notes
- 对象类型：TypeScript 对象类型、type 与 interface
- 函数检查：TypeScript 中的 strictFunctionTypes
- Python 对照：Python Protocol 与结构化类型
TypeScript 结构化类型与函数兼容性
一句话定义
TypeScript 主要采用 structural typing。类型兼容性主要取决于值是否拥有目标类型所要求的成员及兼容的成员类型，而不是类型声明的名字或继承关系。对于 fresh object literals，TypeScript 还会额外执行 Excess Property Checking，因此它们有时会表现得比普通结构兼容检查更严格。
interface HasId {
id: string;
}
const user = { id: 'u1', name: 'Lin' };
const identifiable: HasId = user;额外的 name 不妨碍赋值，因为使用方只承诺读取 id。
心智模型
把 TypeScript 想成在问：
“这个值至少有没有我接下来要用到的这组能力/字段？”
它通常不关心这个值“名义上叫什么类型”，而关心形状是否满足契约。因此一个对象即使从未显式 implements 某接口，只要拥有接口要求的成员，也可以被当作该接口使用。
值
↓
目标类型要求 { id: string }
↓
检查：有没有兼容的 id？
├─ 有 → 可以使用，多出来的成员通常无妨
└─ 没有 / 类型不兼容 → 拒绝Fresh object literal 是额外的一道“防手误门禁”：它在结构兼容之外再做 Excess Property Checking。这个检查不是另一套类型系统，而是为了更早发现拼错字段、写错对象结构等问题。
新鲜对象检查
[!importance] Excess Property Checking fresh object literal 被直接放进一个明确的目标对象类型上下文时，会触发 Excess Property Checking。 这个机制主要用于发现多写、拼错或写错目标对象成员的常见错误。
对象字面量直接赋值时会执行额外属性检查，帮助发现拼写错误：
const value: HasId = { id: 'u1', nmae: 'Lin' }; // 报错这不是结构化类型失效，而是对象字面量获得了更严格的防错检查。
脑图
普通赋值 / 已有变量
↓
Structural Compatibility
↓
“你至少拥有目标类型要求的字段吗？”
↓
多字段通常没关系
fresh object literal
↓
Structural Compatibility
+
Excess Property Checking
↓
“你是不是还写了目标类型不认识的字段？”函数兼容性
回调是否兼容不仅看返回值，还涉及参数方向。开启 strictFunctionTypes 后，函数参数会得到更安全的检查，避免把只能处理窄类型的函数交给需要处理宽类型的位置。
这里的核心仍然是“调用方能否安全使用这个值”：如果某个位置承诺会传入更宽的一组参数，那么被赋进去的函数就不能只会处理更窄的情况。
面试 / 交流表述
TypeScript 是结构化类型系统，兼容性主要看成员形状而不是声明名。已有变量通常只要至少满足目标类型需要的字段即可；fresh object literal 还会触发 Excess Property Checking，它更像一层防拼写和防误用检查，而不是改变了结构化类型的本质。函数类型上则还要考虑参数方向，
strictFunctionTypes会避免把只能接受更窄输入的函数放到需要处理更宽输入的位置。
工程意义
- 接口可以描述“最低能力”，无需显式 implements。
- 测试替身只需满足被测代码真正使用的形状。
- 过大的接口会让实现和测试一起变重，应保持接口聚焦。
- 结构兼容不验证运行时来源；网络数据仍需校验。
Digital Biome