TypeScript中Intersection types与interfaces的区别及适用场景

场景复现 #

你提到的两种类型组合实现代码如下：
交叉类型实现方案：

type Admin = {
    name : string,
    privileges : string[]
}
type Employee ={
    name : string,
    startDate : Date
}

type ElevatedEmployee = Admin & Employee;

const el : ElevatedEmployee ={ // 赋值时缺属性会触发编译报错
    name : 'Max',
    privileges :['create server'],
    startDate : new Date()
}

接口继承实现方案：

interface Admin {
    name : string,
    privileges : string[]
}

interface Employee {
     name : string,
    startDate : Date
}

interface Combined extends Admin, Employee { 
  // 接口声明阶段不需要写属性实现，不会报错
}

首先要纠正一个误解：你观察到的“接口继承时不在接口体内实现属性不报错”根本不是二者的功能差异。不管是交叉类型还是接口，本身都只是类型规则的声明，本来就不需要在声明阶段写属性实现——你定义type ElevatedEmployee = Admin & Employee的时候也没把所有属性列一遍，TS一样不会报错。两者的类型校验都是在给对应类型的变量赋值时才触发，只要赋值时缺了必填属性，不管你是用交叉类型还是接口继承定义的类型，编译器都会报错，这部分校验逻辑完全一致。

• 扩展逻辑不同
  接口的extends是带校验的继承：TS在声明继承接口时，会先检查所有被继承的父类型之间的属性兼容性，如果同名属性的类型存在冲突，会直接在接口声明阶段抛出编译错误。比如如果Admin中name类型为string，Employee中name类型为number，写interface Combined extends Admin, Employee时TS会直接提示类型不兼容，不让你通过编译。
  交叉类型&是无前置校验的聚合合并：TS会直接把所有传入类型的属性做合并，同名属性会取多个类型的交叉结果，不会在类型声明阶段做兼容性校验。还是上面name类型冲突的场景，交叉后name的类型为string & number（即never），TS不会在定义交叉类型的时候报错，只有在实际给name属性赋值时才会触发类型错误。
• 支持的类型范围不同
  接口只能描述对象、类的结构类型，没法表达基础类型别名、联合类型、元组、条件类型、映射类型等非对象结构的类型。比如你没法通过接口继承定义一个字符串类型的别名，也没法用接口直接表达string | null这类联合类型。
  交叉类型是类型别名（type）的组合能力之一，类型别名可以给任意TypeScript类型起别名，覆盖基础类型、联合类型、元组、复杂工具类型等所有TS支持的类型，适用范围远大于接口。
• 声明合并能力不同
  接口支持声明合并：同一作用域下多次声明同名接口，TS会自动将所有声明的属性合并到同一个接口类型中。这个特性常用来扩展第三方库或者全局环境的类型定义。
  类型别名不支持重复声明，同一作用域下出现同名type声明会直接抛出“重复标识符”的编译错误。

• 优先选接口的场景：
  • 定义对象、类的公共结构契约时，尤其是面向对象开发模式、定义对外API类型约束时，接口的继承语义更直观，还能在声明阶段提前捕获父类型的属性冲突问题，减少后续赋值时的类型错误。
  • 需要扩展全局类型或者第三方库的类型定义时，只能通过接口的声明合并能力实现。
• 优先选交叉类型（搭配类型别名）的场景：
  • 需要组合的类型不是纯对象结构，比如要合并联合类型、元组、基础类型相关类型时，只能使用交叉类型。
  • 编写复杂类型逻辑（比如自定义工具类型、条件类型、映射类型）时，类型别名搭配交叉类型的表达能力更强，能覆盖接口做不到的类型运算场景。
  • 需要对同名属性做交叉合并、不需要提前做父类型兼容性校验时，选择交叉类型。

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