在 TypeScript 中，我们经常会遇到这样一个“神奇”的现象：即使函数要求的参数类型是 A，你传入一个类型为 B 的对象，只要它具有与 A 相同的结构，程序就能正常编译并运行，不会抛出任何错误。
一个例子：类型不同但能正常工作
来看这个示例代码：
interface Point {
x: number;
y: number;
}
interface Coordinate {
x: number;
y: number;
z: number;
}
function logPoint(p: Point) {
console.log(p.x, p.y);
}
const coord: Coordinate = { x: 10, y: 20, z: 30 };
logPoint(coord); // ✅ 编译通过，运行正常
这里 logPoint 明确要求参数类型为 Point，但我们传入了一个 Coordinate 类型的对象，TypeScript 不仅没有报错，而且运行也完全没问题。这是为什么？
什么是结构性类型系统？
TypeScript 使用的是一种被称为 结构性类型系统（Structural Type System） 的机制。
简单来说，在这种类型系统中，只要你的数据“长得像”目标类型，它就可以被当作该类型使用。这就是“鸭子类型”（Duck Typing）的概念：
如果它走起来像鸭子，叫起来像鸭子，那么它就是鸭子。
这和一些传统语言（比如 Java 或 C#）中使用的 名义类型系统（Nominal Type System） 完全不同，在那些语言中，类型名是否相同 或者 是否继承了某个接口 才是判断能否赋值的关键。
编译期 vs 运行期：结构一致为什么就可以？
编译期：TypeScript 只看结构
TypeScript 的类型检查发生在 编译阶段，并不会生成任何运行时类型检查代码。它检查的逻辑大致是：
- 你传入的对象是否具有目标类型所要求的属性
- 属性的类型是否匹配
也就是说，只要结构满足要求，就认为是合法的。例如：
const obj = { x: 1, y: 2, z: 3 };
const p: Point = obj; // OK！
运行期：JavaScript 根本不知道类型
TypeScript 最终会被编译为 JavaScript，而 JavaScript 是一门动态语言，它根本就不关心变量的类型名：
function logPoint(p) {
console.log(p.x, p.y);
}
传什么类型的对象进去只要有 .x 和 .y 属性，它就能运行成功。
对比：结构性 vs 名义类型系统
来看一个在 Java 中的例子：
class Point {
public int x;
public int y;
}
class Coordinate {
public int x;
public int y;
public int z;
}
void logPoint(Point p) { ... }
Coordinate c = new Coordinate();
logPoint(c); // ❌ 编译错误：类型不匹配
在 Java 中，Coordinate 不是 Point 的子类，因此不能赋值或传参。结构相同不够，类型名也必须匹配。
而 TypeScript 中，完全没有这种限制：
const c: Coordinate = { x: 1, y: 2, z: 3 };
logPoint(c); // ✅ 合法
结构性类型的优点和风险
✅ 优点
- 灵活性强：无需建立显式的继承或类型关系
- 更贴近 JavaScript 编程习惯：JS 中对象是动态结构，TS 保持一致
- 类型复用性高：结构一致即可使用，提升开发效率
❌ 风险
- 语义歧义：结构相同但含义不同，例如
User和Product都有id - 大型项目中可维护性降低：边界模糊，难以追踪接口实际用途
- 对象“滥用”：容易误将不相关的对象用于某些接口
总结
TypeScript 的结构性类型系统是一种兼顾灵活性与静态类型检查的设计。它让我们在保留 JavaScript 动态性的同时，获得了类型带来的安全性与开发体验提升。
但同时我们也需要明确：
结构相似 ≠ 语义一致
要正确、安全地使用结构性类型系统，就要在灵活和边界之间取得良好的平衡。
如果你觉得这篇文章对你有帮助，欢迎点赞 👍、收藏 ⭐、评论 💬，我会持续分享更多 TypeScript 和前端类型系统的实战解析！
