很少有 TypeScript 问题能像 TypeScript 接口与类型 那样引起如此多的争论。许多文章列出了过去在旧版本中很重要但现在已经过时的差异。因此，我们没有重复声明，而是对其进行了测试。

我们编写了一个文件来验证每个差异，并在严格模式下使用 TypeScript 5.6.3 进行检查。下面引用的编译器错误来自该运行。版本之间的行为可能会发生变化，因此请检查您的项目使用的 TypeScript 版本。如果您是该语言的新手，请从我们的 TypeScript 初学者教程 开始。

简短的回答

interface 描述了对象的形状，并且可以扩展或重新打开。 type 别名为 任何 类型提供名称，包括对象、联合、元组和函数类型。两者都可以工作，区别主要在于风格。

它们哪里相同

这两个声明描述了相同的形状：

interface User {
  id: number;
  name: string;
  email?: string;
}

type UserAlias = {
  id: number;
  name: string;
  email?: string;
};

const a: User = { id: 1, name: "Asha" };
const b: UserAlias = a;   // no error

TypeScript 使用结构类型，这意味着它比较形状而不是名称。这就是为什么 User 可以毫无怨言地分配给 UserAlias。两者都支持可选属性、readonly属性、方法和索引签名。

接口与类型并排

只有打字才能做什么

许多有用的类型根本不是对象形状，只有类型别名才能命名它们：

type Status = "pending" | "paid" | "shipped";   // union
type Point = [number, number];                    // tuple
type Handler = (event: string) => void;           // function type
type Keys = keyof User;                           // computed type
type ReadonlyUser = Readonly<User>;               // utility type

联合类型是 TypeScript 最有价值的功能之一，因为编译器会拒绝列表之外的任何值：

let s: Status = "paid";
s = "refunded";

// error TS2322: Type '"refunded"' is not assignable to type 'Status'.

这可以在编译时捕获拼写错误和过时的值，然后再到达生产环境。

声明合并

如果您两次声明同一个名称的接口，TypeScript 会将它们合并为一个：

interface Settings {
  theme: string;
}
interface Settings {
  language: string;
}

const settings: Settings = { theme: "dark", language: "en" };   // no error

使用类型别名尝试同样的事情，编译器会拒绝：

type Config = { theme: string };
type Config = { language: string };

// error TS2300: Duplicate identifier 'Config'.

合并是库让您扩展其类型的方式。例如，您可以将自定义属性添加到全局 Window 接口或框架的请求对象，而无需修改库。这确实有用。

另一方面是合并可能会意外发生。如果项目中的两个文件在同一范围内声明一个具有相同名称的接口，它们会默默地合并，这可能会造成混乱。相反，类型别名会使该冲突成为错误。

延伸与交叉点

两者都允许您在现有类型的基础上进行构建：

interface Admin extends User {
  permissions: string[];
}

type AdminAlias = UserAlias & { permissions: string[] };

对于兼容的属性，结果是相同的。差异表现为冲突。当接口尝试以不兼容的方式更改属性的类型时，编译器会立即报告：

interface Base { id: number }
interface Broken extends Base { id: string }

// error TS2430: Interface 'Broken' incorrectly extends interface 'Base'.
//   Types of property 'id' are incompatible.
//     Type 'string' is not assignable to type 'number'.

交叉点在声明时不会抱怨。相反，冲突的属性变为 never，这是任何值都不能拥有的类型。该错误仅在稍后您尝试使用它时出现：

type Mixed = { id: number } & { id: string };
const m: Mixed = { id: 1 };

// error TS2322: Type 'number' is not assignable to type 'never'.

后来的错误更令人困惑，因为它偏离了实际的错误。这是在构建对象类型时更喜欢 extends 的实际原因之一。

类和工具

类可以承诺使用 implements 来匹配形状，这适用于接口或对象类型别名：

class Account implements User {
  constructor(public id: number, public name: string) {}
}

这编译没有错误。请注意，implements 仅检查类是否匹配。它不添加任何属性或代码。类无法实现联合类型，因为没有单一的形状可以匹配。

只读和实用类型

Readonly、Partial、Pick 和 Omit 等实用程序类型可与接口和别名一起使用。结果是一个新类型，通常用类型别名命名：

const r: ReadonlyUser = { id: 3, name: "Dev" };
r.name = "Chitra";

// error TS2540: Cannot assign to 'name' because it is a read-only property.

请记住，readonly 只是编译时检查。在运行时，该对象是普通的 JavaScript，并且仍然可以通过绕过类型的代码进行更改。

编译器性能

TypeScript 团队自己的性能指南建议优先使用使用 extends 的接口而不是大型交叉点，因为编译器可以更有效地缓存接口关系。在中小型项目中，您不太可能注意到任何差异。对于具有深度组合类型的非常大的代码库来说，这可能很重要。我们自己没有测量这个。

你应该使用哪个？

根据 TypeScript 手册的指导，广泛使用的规则是：

• 将 interface 用于对象形状，尤其是公共 API 以及类实现或其他可能扩展的任何内容。
• 对联合、元组、函数类型以及映射或计算类型使用 type。

有些团队只是在各处使用 type，这也很有效。最重要的是一致性，所以选择一个约定，将其写在你的风格指南中，并让 linter 强制执行它。 typescript-eslint 中的 ESLint consistent-type-definitions 规则可以做到这一点。

常见错误

• 无休止的争论。 两者对于对象来说都很好，所以确定一次规则然后继续前进。
• 意外合并。 在同一范围内重复使用接口名称会默默地组合它们。
• 冲突的交叉点。他们稍后创建never种带有令人困惑的错误的类型。
• 运行时信任类型。它们会被删除，因此请验证外部数据。
• 使用any消除错误。它关闭检查。更喜欢unknown并缩小范围。

在现有代码库中在它们之间切换

将 interface 更改为 type 或相反，对于普通对象形状通常是安全的，因为 TypeScript 通过结构而不是名称来比较类型。在切换之前仍需要检查一些事项：

• 将接口转换为类型别名会删除声明合并，因此任何具有相同名称的第二个声明都会成为重复标识符错误。
• 将类型别名转换为接口仅适用于对象形状。联合、元组和映射类型必须保留为类型别名。
• 错误消息和编辑器悬停可能会以不同的方式显示类型，这可能会让队友感到惊讶，但不会改变行为。

在一个集中的拉取请求中进行更改，在严格模式和测试套件下运行编译器，并避免将其与功能工作混合，以便审阅者可以看到没有其他任何更改。

最后的话

接口与类型问题有一个冷静的答案：它们对于对象重叠，每个都有一些独特的功能，并且一致性比选择更重要。除非您的团队更喜欢其他方式，否则请使用形状和类型的界面来处理其他一切。要亲自查看差异，请将上面的示例复制到文件中并对其运行 tsc --noEmit --strict。

常见问题

继续学习