TypeScript中B为A子类时，联合类型A|B的实用场景探讨

你提到的这种写法看似冗余，但在不少场景下其实有实际价值，结合你接手的TypeScript 3.2旧项目，主要有这几个实用场景：

• 明确限制类型范围，避免意外传入其他子类
  假设A是父类，B是它的一个子类，但还有其他子类（比如C、D）也继承自A。如果代码逻辑只需要处理A或B的实例，用A | B就能明确约束输入/输出的类型，防止其他子类（比如C）被误传入。在TypeScript 3.2中，这种约束会直接在编译阶段生效，避免后续逻辑处理不符合预期的类型。

  举个实际代码例子：

  class Animal { name: string; }
  class Dog extends Animal { bark(): void {} }
  class Cat extends Animal { meow(): void {} }
  
  // 仅处理通用Animal或Dog，不接受Cat
  function careForPet(pet: Animal | Dog) {
    if (pet instanceof Dog) {
      pet.bark(); // 安全调用Dog独有的方法
    } else {
      console.log(`Feeding ${pet.name}`);
    }
  }
  
  careForPet(new Cat()); // TS3.2中会直接报错，阻止不符合预期的类型传入
  

  要是换成Animal类型，careForPet(new Cat())编译不会报错，但逻辑里并没有处理Cat的情况，运行时可能出现问题。

• 借助类型窄化实现更精准的类型推断
  使用A | B时，TypeScript的类型窄化（比如instanceof、属性检查）能自动识别出B类型，让你直接调用B独有的方法，无需额外的类型断言。如果只用A类型，要调用B的方法必须手动断言，代码不仅繁琐，还容易因断言错误导致运行时问题。

  对比两种写法：

  // 使用A | B的情况
  function processItem(item: A | B) {
    if (item instanceof B) {
      item.bOnlyMethod(); // 直接调用，无需断言
    } else {
      item.aCommonMethod();
    }
  }
  
  // 只用A的情况
  function processItem(item: A) {
    // 必须手动断言才能调用B的方法
    (item as B).bOnlyMethod();
    // 或者先判断再断言，代码更啰嗦
    if ('bOnlyMethod' in item) {
      (item as B).bOnlyMethod();
    }
  }
  

  在TypeScript 3.2中，类型窄化的能力虽然不如新版本完善，但联合类型的窄化依然比单独使用父类更便捷。

• 兼容旧版本TypeScript的类型系统局限
  TypeScript 3.2的协变/逆变支持不如新版本宽松，比如在数组、函数参数的类型处理上可能存在一些限制。当时的开发者可能用A | B来绕过某些编译报错——比如在某些复杂场景下，将B[]赋值给A[]可能触发类型检查错误，而改用(A | B)[]就能解决这个问题。这种写法是为了适配旧版本的类型检查逻辑。

• 代码意图的文档化
  写A | B相当于一种代码级的文档，明确告诉后续维护者：这个变量的取值范围是父类A或者它的特定子类B，而不是任意A的子类。相比单纯写A，这种写法能更清晰地传达业务逻辑的预期，降低后续维护的理解成本。

内容的提问来源于stack exchange，提问作者Jake