别再一股脑用 TypeScript 的 Interface 了

最新推荐文章于 2025-11-26 15:04:42 发布

原创最新推荐文章于 2025-11-26 15:04:42 发布 · 227 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#typescript #前端 #javascript

何时用接口的合并？ ——扩展库的公共接口（比如为 @auth/core 的 Session 增补字段）是合理用法。除此之外，日常业务里滥用合并，容易踩坑。

两者功能高度重叠，于是问题来了：谁更好？

这篇文章会系统对比 type 与 interface，并解释为什么在大多数场景里，你更应该优先选 type。

让我们直接开始。

它们到底有啥差别？

先看一个最朴素的 “Person” 定义：

type Person = {
  name: string
  age: number
}

interface Person {
  name: string
  age: number
}

乍看几乎一样——只不过 type 用 = 赋值出一个“形状”，而 interface 直接声明。

当然，区别不止于此。继续往下拆。

可扩展性（Extensibility）

很多人会说：接口在“可扩展”上是天然赢家，因为它能用 extends 扩展其它接口：

// 接口扩展
interface Job {
  job: string
}

interface Person extends Job {
  name: string
  age: number
}

const person: Person = {
  name: 'John',
  age: 25,
  job: 'Full-Stack Web Developer',
}

但 type 也能扩展——借助交叉类型 & 或联合类型 | 做组合，而这是接口不能直接表达的：

// ✅ 可行：交叉类型拼装
type Person = {
  name: string
  age: number
} & { job: string }

// ❌ 不可行：interface 不能在声明处用交叉
// interface Person { ... } & { job: string }

结论：如果你偏好“以类型运算搭积木”的风格，type 的表达力更强。

可实现性（Implementation）

在面向对象（OOP）世界，interface 支持被 class 用 implements直接实现，这点与 Java/C# 一致；而 type不能被类直接实现。

// OOP 实现示例
interface Work {
  doWork: () =>void
}

class Person implements Work {
  name: string
  age: number

constructor(name: string, age: number) {
    this.name = name
    this.age = age
  }

  doWork() {
    console.log('Working...')
  }
}

const p = new Person('John', 25)
p.doWork()

结论：如果你大量采用 class + implements 的编码风格，interface 更顺手；否则，type 足够好用。

性能（类型检查速度）

这里说的性能是 TS 编译器的类型检查。随着代码量增长，类型检查耗时会显著升高。比较结果？没有差别。社区与专家（如 Matt Pocock）已明确说明：**type 与 interface 在类型检查性能上几乎为 0 差异**。

选哪个，不影响编译速度——放心用你喜欢的。

为什么 Interface 可能“埋雷”？

interface 有一个 Type 没有的能力：声明合并（Declaration Merging）。

编译器会把同名接口自动合并：

// 初始声明
interface Person {
  name: string
  age: number
}

// 追加声明（合并）
interface Person {
  gender: string
}

const someone: Person = { name: 'John', age: 25, gender: 'Male' }

好处：无需改动源定义，就能给已有接口加字段。例如给第三方库的接口“加料”，很方便。

坏处：可能带来意料之外的行为：