TypeScript interface 和 type 的区别与选择

在描述对象结构这件事上，interface 和 type 做的是同一份工作，只要结构一致，两者的值就可以互相赋值。区别都在边缘地带：type 能为接口无法表达的东西命名（联合类型、元组、计算出来的类型），而接口也能做几件类型别名做不到的事（合并、会做检查的 extends）。

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

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

const a: PointI = { x: 1, y: 2 };
const b: PointT = a; // same shape, so they are interchangeable
const c: PointI = b;

function show(p: PointI): string {
  return `(${p.x}, ${p.y})`;
}

console.log(show(b), show(c)); // (1, 2) (1, 2)

TypeScript 按结构比较对象类型，所以对于能否赋值，声明叫什么名字并不重要。下面列出的是选择真正会产生影响的地方。

对比表

只有 type 能做的事

凡是不止一个对象结构的东西，都需要类型别名：

type Status = "idle" | "loading" | "done";                   // union of literals
type Coordinates = [lat: number, lng: number];               // tuple
type Handler = (event: string) => void;                      // function type
type ID = string | number;                                   // union of primitives
type Flags<T> = { [K in keyof T]: boolean };                 // mapped type
type ElementOf<T> = T extends readonly (infer U)[] ? U : T;  // conditional type

const current: Status = "loading";
const here: Coordinates = [51.5, -0.12];
const onSave: Handler = (e) => console.log("saved:", e);
const flags: Flags<{ dark: string; beta: number }> = { dark: true, beta: false };
const first: ElementOf<string[]> = "a";

onSave(current);
console.log(here, flags, first);
// saved: loading
// [ 51.5, -0.12 ] { dark: true, beta: false } a

这些都无法用 interface 写出来（最后两种分别在 映射类型 和 条件类型 中介绍）。这就是为什么不管对象结构用的是什么，每个代码库最终都会在某些地方用到 type。

只有 interface 能做的事：声明合并

同一作用域中两个同名的 interface 声明会合并成一个。两个同名的 type 声明则会报错 TS2300：Duplicate identifier。

interface Settings {
  theme: string;
}
interface Settings {
  fontSize: number;
}
const s: Settings = { theme: "dark", fontSize: 14 }; // needs both

type Options = { a: number };
type Options = { b: number }; // error TS2300: Duplicate identifier 'Options'.

库的类型正是靠合并从外部扩展的：给全局的 Window、Express 的 Request 或某个库的主题类型添加属性。如果你发布的类型可能需要被使用者扩充，就用接口。在你自己的应用代码中，意外的合并（两个脚本文件声明了同名的全局接口）会悄无声息地发生，除非两者以不同的类型声明了同一个属性；这也是一些团队偏爱 type 的理由之一。

extends 与交叉类型

接口用 extends 扩展，类型别名用 &。两者的结果大多相同，但处理冲突属性的方式不同。extends 会在声明处报告冲突：

// This does not compile: id cannot change from string to number
interface Base {
  id: string;
  name: string;
}

interface Broken extends Base {
  id: number;
}

const x: Broken = { id: 1, name: "a" };
console.log(x);

index.ts(7,11): error TS2430: Interface 'Broken' incorrectly extends interface 'Base'.
  Types of property 'id' are incompatible.
    Type 'number' is not assignable to type 'string'.

交叉类型会默默接受同样的冲突，把这个属性变成 never（一个同时是 number 的 string）。错误要到后面你尝试创建值时才出现：

type Base = { id: string; name: string };
type Broken = Base & { id: number }; // no error here

// id is string & number, which is never: no object can satisfy Broken
// @ts-expect-error: Type 'number' is not assignable to type 'never'.
const x: Broken = { id: 1, name: "a" };

console.log("the alias compiled; only using it failed");

错误指向的是那个对象，离引发它的声明很远。在用其他对象类型构建对象类型时，extends 给出的提示更好。

索引签名：一个容易忽略的区别

对象类型的类型别名会得到一个隐式的索引签名，所以可以传给需要 Record<string, unknown> 的地方。接口则不会。这是有意为之：TypeScript 团队的解释（TypeScript 仓库的 issue #15300）是，接口可以被后续的声明扩充，因此为它推断索引签名不够安全，而现在改变这条规则又会破坏太多代码。

interface UserI { name: string; age: number }
type UserT = { name: string; age: number };

function logFields(fields: Record<string, unknown>) {
  for (const [key, value] of Object.entries(fields)) {
    console.log(`${key}=${String(value)}`);
  }
}

const t: UserT = { name: "Ada", age: 36 };
const i: UserI = { name: "Alan", age: 41 };

logFields(t); // fine

// @ts-expect-error: Index signature for type 'string' is missing in type 'UserI'.
logFields(i);

logFields({ ...i }); // a spread copy is a fresh object type, so it is accepted

标了 @ts-expect-error 的那次调用照样会运行，并输出 Alan 的字段：这条规则只在编译时生效。把接口类型的值传给参数类型为 Record<string, ...> 的日志、序列化或查询辅助函数时，出现令人困惑的错误，通常就是这个原因。可以把那一个声明改成 type，展开这个值，或者把辅助函数的参数改用接口或泛型来声明。

性能与错误提示

TypeScript wiki 的 Performance 页面（“Preferring Interfaces Over Intersections”一节）建议，在组合对象类型时用 interface Foo extends Bar, Baz { ... }，而不是 type Foo = Bar & Baz & { ... }。理由是：接口是一个能检测属性冲突的扁平对象类型；接口之间的类型关系会被缓存（交叉类型整体则不会）；而检查一个值是否符合交叉类型时，会先逐个检查每个组成部分，再检查扁平化后的类型。在有大量组合类型的大型代码库中，这个差别才有意义；对于几个普通的对象结构，你根本测不出来。

同一页面还指出，接口的显示效果更好。在悬停提示和错误信息中，接口显示为它的名字，而交叉类型别名常常被展开成各个部分打印出来，让长长的信息更难读。

该用哪一个

一条行得通的规则：

1. 对象结构：用 interface。它提供会做检查的 extends，在大型组合上错误更清晰，还允许库的使用者扩充它。这与 TypeScript 手册的经验法则一致：“在需要用到 type 的特性之前，都用 interface”。
2. 其他一切：用 type。联合类型、元组、函数类型、字面量类型，以及任何用映射类型、条件类型或模板字面量类型构建的东西。
3. 例外：如果对象结构需要符合 Record<string, ...> 参数，或者你有意阻止合并，就用 type。

全部使用 type 也是一种自洽的选择，很多代码库就是这么做的。唯一要避免的是随意混用两者：这会让读代码的人疑惑，这里的差别是不是有意为之。