TypeScript interface vs type 对比

文章目录

• 前言
• TypeScript `interface` vs `type` 对比
• • 1. 语法差异
  • 2. 使用场景推荐
  • 3. 扩展性与兼容性
  • 4. 编译后行为
  • 5. 与第三方类型系统集成建议

前言

TypeScript 中的 interface 与 type 做一个深入对比，包括语法特性、使用场景、兼容性与扩展性，以及底层行为差异。

TypeScript interface vs type 对比

在 TypeScript 中，可以用 interface（接口）或 type（类型别名）两种方式定义类型。它们有诸多相似之处，但在语法、使用场景、扩展性、编译行为和与第三方库集成等方面存在差异。下面从这五个维度进行详细对比，并结合代码示例、表格说明差异点，最后总结最佳实践。

1. 语法差异

定义语法：

• 接口 (interface) 定义： 使用 interface Name { … } 声明对象的结构或函数的签名。例如定义一个点坐标接口：

  interface Point {
  x: number;
  y: number;
  }

  接口也可用于定义函数类型，写法是在接口内部直接声明调用签名，如：

  interface SetPoint {
  (x: number, y: number): void;
  }

  上述 SetPoint 接口表示一个接受两个参数且无返回值的函数类型。

• 类型别名 (type) 定义： 使用 type Name = … 给任何类型起别名。它可以是对象、基本类型、联合/交叉类型等。例如同样定义点坐标类型：

  type Point = {
  x: number;
  y: number;
  };

  定义函数类型别名：

  type SetPoint = (x: number, y: number) => void;

  可以看出，用 type 定义对象类型时需要使用 = 号赋值，并在对象字面量后加分号。

继承与组合：

• 接口继承 (extends)： 接口可以通过 extends 继承另一个接口，从而扩展其属性：

  interface Animal { name: string; }
  interface Bear extends Animal { honey: boolean; }
  // Bear 拥有 name 和 honey 两个属性

  如果要继承多个接口，可以使用逗号分隔多个接口名称。例如 interface C extends A, B { … }。接口只能继承接口或类型别名所表示的对象类型。

• 类型别名交叉 (&)： 类型别名本身不能使用 extends 关键字，但可以通过交叉类型（intersection &）来组合：

  type Animal = { name: string; };
  type Bear = Animal & { honey: boolean; };
  // Bear 拥有 name 和 honey 两个属性

  交叉类型将多个类型合并为一个类型，达到类似继承的效果。需要注意，交叉合并时如果属性冲突，TypeScript 会推导出 never（即不存在可满足双方要求的类型）。而接口继承在遇到属性类型冲突时会直接报错，强制开发者处理冲突，这通常是更合理的行为。

声明合并： 接口是开放的，允许多个同名接口声明会被自动合并。类型别名是封闭的，不能重复声明同名的类型别名。比如：

interface Kitten { purrs: boolean; }
interface Kitten { color: string; }
// 两次声明会合并为一个 Kitten 接口，拥有 purrs 和 color 两个属性

type Puppy = { color: string; };
// type Puppy = { toys: number; }; // 错误：重复定义同名类型别名

如上，第二次声明接口 Kitten 时，会将新属性合并进去，等效于一个接口包含所有属性。而类型别名 Puppy 无法二次声明，否则编译错误。因此接口可以扩展已有定义（尤其在声明全局类型时很有用），类型别名则不支持合并（更严格地保持单一定义）。

其他语法差异：

• 接口名称在错误信息中保留原名，类型别名有时会展开成具体定义。例如，当类型别名很复杂时，TypeScript 报错可能直接显示展开后的具体类型，使错误信息冗长。而接口由于创建了一个显式的名字，错误提示通常会直接引用接口名，更简洁聚焦。这一点在调试大型类型时能提高可读性。
• 接口不能直接表示基本类型别名或联合类型，而类型别名可以为几乎任何类型命名（详见下文场景部分）。接口只能用于对象形状或函数的结构描述。相对地，type 可用于基本类型、元组、联合、条件类型等更多场景，这属于语法上的灵活性差异。

下面的表格总结了主要语法特性支持情况：

2. 使用场景推荐

根据接口和类型别名各自的特性，在不同场景下有推荐的使用方式：

• 组件 Props 定义： 在 React 和 Vue 等框架中定义组件的 props 类型时，接口通常是首选。接口更符合“描述对象结构”的语义，而且可以拓展（例如在高阶组件或扩展 HTML 原生属性时更方便）。React 社区中，不少人偏好用接口来定义 Props 和 State，因为接口支持扩展和合并，类型检查错误信息也更清晰。例如在 React 中：

  // 用接口定义组件Props
  interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  label: string;
  }
  function Button({ label, …rest }: ButtonProps) {
  return <button {…rest}>{label}</button>;
  }

  上例中接口通过 extends 轻松继承了原生按钮属性类型，附加了自定义的 label 属性。如果用类型别名，则需要交叉类型 & 来组合，虽功能等效但在大型项目中可能引入性能问题（下文详述）。实践经验表明，当需要将多个来源的Props组合时，使用接口的 extends 对编译器更友好、更高效。 注： 在简单场景下（比如无需扩展的局部Props)，使用 type 定义也完全可行。官方 React 文档指出，Props 类型本质上就是一个对象类型，用 type 或 interface 定义均可。因此团队可根据习惯选一种，但应保持一致和清晰。

• 联合类型 (Union Types)： 如果一个类型需要表示“几种类型之一”，只能使用类型别名来定义。例如：

  type Input = { tag: 'text'; text: string }
  | { tag: 'checkbox'; checked: boolean };

  以上定义了一个联合类型 Input，可能是文字输入或复选框两种形态。接口本身不能直接表达联合类型（无法声明 interface X = A | B 这种语法）。尽管可以定义多个接口如 TextInput 和 CheckboxInput 再用类型别名联合，但最终还是通过 type 来组合。在需要判别联合（discriminated union）模式的场景，type 是必然选择。

• 工具类型 (Utility Types)： TypeScript 提供了许多内置工具类型（如 Partial<T>, Required<T>, Pick<T, K>, ReturnType<F> 等），以及可以自定义条件类型和映射类型来变换类型结构。这类高级类型机制只能使用 type 实现。例如，用映射类型定义一个全部属性只读的工具类型：

  type ReadonlyObj<T> = { readonly [K in keyof T]: T[K] };

  或条件类型定义一个类型筛选：

  type ElementType<T> = T extends (infer U)[] ? U : T;

  这些场景下接口都无能为力——接口不能在定义时使用映射或条件语法。因此工具类型几乎都是用 type 定义的。换言之，当需要利用类型编程的高级特性（条件判断、映射、模板字面量类型等）时，type 是唯一选择。

• 内置对象类型扩充： 如果需要扩展全局作用域中已有的类型（例如为 Window 对象添加属性，或为第三方库的类型增加自定义字段），接口更适合。因为接口支持声明合并，可以直接重复声明同名接口来增加属性。典型例子是在 global.d.ts 中扩展浏览器 Window 接口：

  // 扩展全局 Window 接口，增加自定义属性
  declare global {
  interface Window { myAppVersion: string; }
  }

  这样即使原始 Window 在 lib.dom.d.ts 中已定义，也会合并进新的字段。而类型别名不支持重复声明，因此无法用同名 type Window = … 来扩展。此外，许多第三方库也利用接口合并机制提供了插件式的类型扩展能力。比如 Express 框架允许声明 declare module 'express' { interface Request { … } } 来扩展请求对象类型。这类场景必须使用接口的声明合并特性。

• 封闭数据模型： 如果你有些数据结构确定不希望被再扩展修改，使用类型别名可以体现这一意图。由于类型别名是不可合并的，“封闭”了定义，可以防止外部再添加属性。虽然 TS 没有真正的访问控制，但通过选用类型别名，可以在团队约定上表示此类型不应再被扩展。比如定义一个固定格式的配置项：

  type Config = {
  readonly host: string;
  port: number;
  };

  用接口也可以做到相同效果，只是接口始终允许被再次声明。所以在追求严格不可变的契约时，一些开发者会偏好用 type 来定义对象类型，以避免接口可能被合并的“开放”行为。

简单来说，一个常见的经验法则是：“在不知道选哪种时，先使用接口，当需要类型别名独有的功能时再切换”。TypeScript 官方文档也提供了类似建议：“大部分情况下可以按喜好选择，TypeScript 会在需要时告诉你用另一种。如果要一个启发式，用接口直到你需要用 type 的特性为止”。因此默认用接口描述对象结构，当要定义联合、高级映射/条件类型或基本类型别名等接口无法覆盖的情况，就使用类型别名。

3. 扩展性与兼容性

开放 vs 封闭： 如前所述，接口是开放的，可以多次声明同名接口实现声明合并。这种特性提供了极高的扩展性：不同模块都可以向同一个接口增加字段，最终都会合并成一个类型。例如很多库的全局类型扩展都是基于接口合并实现的。相反，类型别名是封闭的，不能在初次定义后再增加新成员。这意味着类型别名更具确定性，一旦定义不会被偷偷修改。开放性有利于扩展大型应用或库的类型，但也可能在无意中导致冲突或难以跟踪来源。因此，在需要插件式扩展时选接口，需要固定契约时选类型别名，这取决于兼容性的需求。

接口与类型可互相兼容： 虽然语法上有所区别，但接口定义的类型和类型别名定义的类型在 TypeScript 的结构类型系统下完全兼容。也就是说，一个用接口声明的对象类型可以赋值给一个等价结构的类型别名，反之亦然。甚至接口和类型别名可以互相扩展：接口能 extends 类型别名（前提类型别名表示的是对象结构）；类型别名也能通过交叉类型包含接口。例如：

type X = { a: number };
interface Y { b: string; }

interface Z extends X { c: boolean; } // 接口继承类型别名 X
type W = Y & { d: Date; }; // 类型别名交叉接口 Y

let z: Z = { a: 1, c: true };
let w: W = { b: "hi", d: new Date() };

上例中接口 Z 成功继承了类型别名 X 的结构，而类型别名 W 也通过 & 包含了接口 Y 的属性，可见二者可以灵活混合。**类实现 (implements)**方面，类既可以实现接口，也可以实现类型别名（只要该类型别名实际是对象结构而非联合类型）。例如：

interface Shape { area(): number; }
type Serializable = { toJSON(): string; };

class Circle implements Shape, Serializable {
// 同时实现接口 Shape 和类型别名 Serializable 定义的要求
area() { /* … */ }
toJSON() { /* … */ }
}

需要注意，如果类型别名是联合类型或其他非对象类型，类无法用 implements 实现它（因为类只能有一种具体结构，实现联合类型没有意义）。

交叉类型 vs 接口继承： 当需要组合多个类型时，接口可以使用继承来扁平化地合并属性，而类型别名通过 & 交叉来叠加类型。二者生成的结果在类型检查上大体相同，但有一些微妙区别：

• 接口继承会检查属性冲突，如果父接口中有同名属性而子接口试图以不同类型覆盖它，将直接报错，要求开发者澄清类型关系。这种行为有助于及早发现逻辑错误。
• 交叉类型对属性冲突更为宽松，它不会立即报错，而是合并成一个不可能满足的类型（如同名属性类型不兼容时会推导为 never 类型）。这可能导致该属性实际不可用但未显式报错，埋下隐患。
• 性能方面，TypeScript 官方说明在组合多个类型时，接口的继承通常比交叉类型更高效。因为接口扩展产生的是一个扁平的单一对象类型，类型关系还可以被编译器缓存；而交叉类型是递归合并的，嵌套交叉可能在检查时反复展开。尤其在大型项目中，过度使用复杂的交叉类型可能使类型检查缓慢。基于这一原因，有性能考虑时建议优先使用接口继承来组合类型，而非交叉类型。

递归与自引用： 接口和类型别名都支持递归定义，即类型中引用自身用于表示嵌套结构。例如定义链表节点：

interface Node {
value: string;
next?: Node; // 接口递归引用自身
}

type NodeType = {
value: string;
next?: NodeType; // 类型别名递归引用自身
};

两种方式均可描述这种递归结构。不过在更复杂的递归场景（比如利用条件类型递归计算），只能用类型别名实现，因为接口无法编写条件判断。此外，TypeScript 对类型别名的递归复杂度有一定限制，如果嵌套过深可能出现编译性能问题，需要借助尾递归优化等高级技巧。但这些属于极端情况，一般的递归引用接口和类型表现相同。

兼容第三方库类型系统： 扩展性也体现为能否无缝与第三方库的类型定义交互。多数情况下接口和类型别名都能很好地兼容使用。例如：

• Redux 的 connect 等高阶组件需要将多个来源的 props 类型合并，这时倾向用接口继承让类型更清晰。
• 一些库会导出联合类型作为API，如 GraphQL 的返回可能是多种类型的联合，则会以类型别名提供。你的代码可直接使用这些 type 定义，或用接口去继承其中的对象类型部分，都没有问题。

总之，在扩展性方面，接口提供了更动态开放的机制，适合需要被扩充和继承的场景；类型别名更静态封闭，适合明确最终形状、不希望被改变的场景。二者的类型兼容性很好，可以根据需要混合使用。官方建议对于公共暴露的API类型，优先使用接口，因为接口更易扩展维护。

4. 编译后行为

无论使用 interface 还是 type，它们都只存在于编译时，在编译后的 JavaScript 中不会生成任何实际代码。也就是说，这两种类型定义方式对运行时性能没有直接影响，纯粹是为了静态类型检查和IDE智能提示服务。

具体而言：

• 接口在编译时被擦除。比如：

  interface Person { name: string; }
  const p: Person = { name: "Alice" };

  编译为JS后只剩下 { name: "Alice" } 这个对象赋值，接口 Person 不会出现在运行时代码中。接口主要用于编译阶段的类型验证，在运行时没有任何检查功能。

• 类型别名同样不会产生运行时代码。它只是为一段类型提供了一个名字，在编译阶段起作用。例如：

  type ID = number | string;
  let userId: ID = 123;

  编译输出的JS代码里也只有 let userId = 123;，类型别名 ID 不会存在。类型别名也无法在运行时动态访问或检查。

由于这两者都没有运行时开销，如果您担心某种类型定义方式会导致额外的JS代码，可以放心——在这点上接口和类型别名的行为是等价的。它们和 TypeScript 的其他类型一样，都是“编译时艺术品”，不会像类 (class) 那样在JS中保留构造函数或方法。正因为如此，用接口或类型别名定义的类型不能用于 instanceof 等运行时操作，也无法通过反射获取类型结构；一切类型检查都在编译阶段完成。

提示： 如果只导入了类型而未使用任何值，TypeScript 编译器会自动删除这些导入（或需要使用 import type 语法）以确保不产生未使用的运行时代码。这进一步证明了接口和类型别名纯粹是零运行时影响的。

5. 与第三方类型系统集成建议

在与 React、Vue、GraphQL 等第三方库或框架协同使用 TypeScript 时，选择 interface 或 type 需要考虑这些生态的惯例和工具链支持：

• React 集成： 对于 React 组件的 Props 和 State 类型，官方和社区均表示可以使用接口或类型别名定义对象类型。不过在实践中，使用接口定义 Props 更为常见。理由包括接口可扩展、错误信息友好，以及在需要从其他类型扩展时书写更简洁。很多教程和代码示例都采用接口，例如 React 官方 TypeScript Cheatsheet 就采用 interface AppProps { … } 的形式定义 Props。而当Props涉及交叉类型组合时（例如组件既有自身属性又要包含 HTML 元素属性），接口的 extends 比类型别名的 & 更利于类型检查性能。因此推荐：React 项目中，简单Props任选其一即可，但复杂Props或公共Props类型倾向于使用接口。值得注意的是，一些团队可能通过 ESLint 规则（如@typescript-eslint/consistent-type-definitions）统一约定 Props 用接口或类型，这主要是代码风格一致性考虑。

• Vue 集成： 在 Vue 3 的组合式 API (Composition API) 中，使用 defineProps<Type>() 来定义组件 props 类型。Vue 的设计对接口和类型别名均支持，但在 Vue 3.2 及之前的版本中，有一项限制：defineProps 的泛型参数只能是字面量对象类型或本地接口，不支持直接引用导入的类型别名。为绕过这一限制，许多 Vue 3 用户当时采用接口来定义 Props，然后在组件内使用该接口（或者直接在 <script setup> 内声明接口再用）。从 Vue 3.3 开始，这一限制有所放宽，defineProps 已支持引用部分导入的类型别名，但仍对复杂类型（如递归的条件类型）有限制。综合考虑，在 Vue 项目中可以：

  • 如果使用 Vue 3.2 或更低版本，建议使用接口定义组件 Props（或者直接在 defineProps<> 内书写对象类型字面量），以确保类型能正确被 Vue 编译器解析。
  • 在 Vue 3.3+ 中，接口或类型别名皆可，根据团队偏好选择。如果 Props 类型相对简单，直接在 defineProps<> 中写对象字面量最直观；如需在多个组件间复用 Props 类型，仍可导出接口或类型别名供 defineProps 引用。接口的好处是可局部声明、不用显式导入文件（在 <script setup> 中直接声明接口即可使用），类型别名则需要 import type 导入外部定义。
  • 注意避免在 defineProps 的类型中使用过于复杂的类型运算（比如全局联合或复杂条件），因为 Vue 的类型推导对这些情况支持有限。如有需要，可考虑将复杂类型拆分，或者在 Prop 类型中使用接口描述基本结构，再通过额外校验来确保更复杂的约束。

• GraphQL 集成： 在使用 GraphQL 或 Apollo 时，会经常通过代码生成器将 GraphQL 模式(schema)生成对应的 TypeScript 类型。老版的 Apollo Codegen 默认生成 接口 来表示 GraphQL 类型，但现代的 GraphQL Code Generator（由 The Guild 开发的工具）更倾向于生成 类型别名。原因在于：GraphQL 模式中有许多联合类型和可选字段，直接映射为 TypeScript 接口会受限，而类型别名更灵活，可表示联合、可选以及索引签名等。例如 GraphQL 中的 union SearchResult = Photo | User，生成 TS 时必须是 type SearchResult = Photo \\| User 才能工作，接口无法直接对应。此外，社区在实践中发现，用类型别名表示纯数据结构更贴切，而接口语义上表示可实例化的契约并不完全吻合 GraphQL 类型的用途。因此建议：使用 GraphQL Codegen 生成类型时，除非有特殊需求，保持默认的类型别名输出即可。如果项目以前使用 Apollo Codegen 且生成的是接口，可以平滑迁移到类型别名形式，类型检查上应无差异。在应用代码中，无需关心这些类型是接口还是类型别名——它们本质都是数据的类型描述，只要结构一致就可以相互赋值使用。唯一需要注意的是，如果打算基于生成的类型做进一步拓展或面向对象建模，比如定义类去实现某个 GraphQL 返回接口，那么可能要调整策略（通常很少这样做，因为解析后的数据往往以直接对象使用）。总体而言，GraphQL 的类型更适合作为类型别名，这也是当前大多数 GraphQL TypeScript 集成方案的选择。

• 其他库 (如Redux/React-Redux, Express等)： 通常库会在文档中说明类型如何定义和扩展。遵循它们的建议选择 interface 或 type 即可。例如 React-Redux 的 connect 类型很复杂，一般不手写而交由库定义，但如果需要自己描述 Props，也推荐接口优先。这些库本身的类型声明文件（*.d.ts）里，我们可以查看它们导出的类型是 interface 还是 type，从而在扩展时选择匹配的方式。

总结最佳实践： 综合以上比较和场景分析，可以整理出以下最佳实践供参考：

• 对象模型和API契约：优先使用 interface。接口更能体现面向接口编程的思想，支持声明合并利于扩展和维护，对公共API（如库的导出类型、组件Props）尤为合适。接口命名清晰，在错误信息中更直观。若日后需要扩展属性，接口也能方便地继承或合并。

• 联合类型或特殊类型：必须使用 type。凡是接口不支持的场景（基本类型别名、联合、元组、条件、映射类型等），type 是唯一选择。比如定义字符串字面量联合、函数重载联合、键映射到新对象等，此时类型别名无可替代。

• 性能考量：在需要组合多个类型时，尽量使用接口的继承而非交叉类型，以减轻编译器负担。如果已经用了大量类型别名交叉，也不必盲目重构，但可以在新代码中避免过深的交叉叠加。微软的官方性能指南建议“使用接口扩展来代替交叉类型”，以获得更快的类型计算和更友好的错误显示。

• 团队一致性：确保团队在风格上达成一致，避免有人用接口有人用类型别名定义相同目的的类型。无论选择哪种方式，应有清晰的约定。例如一些团队规定“对象类型一律用接口，除非需要用 type”，而另一些团队可能倾向“能用 type 就用 type，接口仅用于声明合并场景”。两种路线上都有人坚持，各有理由。如果要参考官方立场，TypeScript 手册提供的启发式是先用接口，必要时再用类型别名。这一原则在实践中也被多数开发者采纳。当然，最终选择应结合项目特点和开发者经验。

总而言之，interface 和 type 在很大程度上可以互换使用，关键是了解它们各自的边界与优势。在定义简单类型时不必纠结，两者均可满足需求。但在设计复杂系统的类型时，合理选择能提高代码的可维护性和性能：让接口承担模块之间的契约角色，让类型别名发挥类型表达力的特长。掌握何时用好它们，将使 TypeScript 的类型系统为你的项目保驾护航。

参考来源：

• TypeScript 官方手册、性能指南和 Playground 示例
• Stack Overflow 等社区经验
• React、Vue 官方文档
• 社区博客与实践案例