TypeScript中为何可将Card[]类型赋值给InterfaceCard[]类型变量？

嘿，这个问题问得太实在了！结合你给出的代码，我给你把背后的逻辑讲得明明白白～

先看你这段核心代码：

// 定义接口
export interface InterfaceCard {
  value: number;
  suit: string;
  getName(): string;
}

// 实现接口的类
class Card implements InterfaceCard {
  value: number;
  suit: string;

  constructor(value: number, suit: string) {
    this.value = value;
    this.suit = suit;
  }

  getName(): string {
    return `${this.value}${this.suit}`;
  }
}

背后其实是TypeScript类型系统的两个关键规则在起作用：

• 类与接口的子类型关系：因为Card类完完整整地实现了InterfaceCard接口的所有成员——不管是属性还是方法，一个都没少，完全符合接口的“契约”。这时候TypeScript就会认定Card是InterfaceCard的子类型，就像苹果是水果的子类型一样，苹果拥有水果的所有特性，Card也拥有InterfaceCard的所有特性，所以把Card实例当成InterfaceCard用绝对安全。

• 数组类型的协变特性：在TypeScript里，如果类型A是类型B的子类型，那A[]（A的数组）也会自动成为B[]（B的数组）的子类型。放到你的场景里，既然Card是InterfaceCard的子类型，那Card[]自然就能毫无障碍地赋值给InterfaceCard[]类型的变量。

打个接地气的比方：你有一筐红富士苹果，苹果属于水果范畴，那把这筐苹果放进“通用水果筐”里完全合理——你从水果筐里拿出来的东西，肯定具备水果的核心特性（能吃、有水分），红富士苹果当然满足这些要求，绝不会出问题。对应到代码里，当你操作InterfaceCard[]变量时，比如遍历每个元素调用getName()，或者访问value、suit，数组里的Card实例都能完美响应，根本不会出现“找不到属性/方法”的错误。

顺便提一句，反过来就不行了——你不能把InterfaceCard[]赋值给Card[]，因为InterfaceCard数组里可能混着其他实现了该接口的类实例（比如另一个MagicCard implements InterfaceCard），这时候把它当成Card来操作就会出问题，这也是协变的单向安全性体现。

内容来源于stack exchange