TypeScript interface、type、abstract class 与泛型对比

interface、type 和 abstract class 都能描述结构，但用途并不完全一样。

interface

interface 常用于描述对象形状，尤其适合公共 API 和类实现。

interface User {
  id: string;
  name: string;
}
 
class Admin implements User {
  constructor(
    public id: string,
    public name: string,
  ) {}
}

interface 可以重复声明并自动合并，这在扩展第三方类型时有用。

type

type 更灵活，可以表达联合类型、交叉类型和复杂组合。

type Status = "idle" | "loading" | "success" | "error";
type UserWithRole = User & { role: string };

如果你要描述的是状态集合、函数类型或复杂类型组合，type 往往更合适。

abstract class

抽象类既可以定义类型，也可以包含共享实现。

abstract class Repository<T> {
  abstract findById(id: string): Promise<T | null>;
 
  logQuery(id: string) {
    console.log(`find ${id}`);
  }
}

如果需要子类共享代码，抽象类比 interface 更合适。

泛型

泛型让类型可以被参数化。

function identity<T>(value: T): T {
  return value;
}
 
const name = identity<string>("Alice");

泛型常用于集合、API 返回值和工具函数。

interface ApiResponse<T> {
  data: T;
  error?: string;
}
 
type UserResponse = ApiResponse<User>;

简单选择规则

描述对象结构：优先 interface
描述联合、交叉、工具类型：优先 type
需要共享实现和继承约束：用 abstract class
需要类型复用：使用泛型

延伸理解

复习这篇时，不要只记住名词，要把重点放在 interface、type、abstract class、泛型约束和公共类型设计。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。

TypeScript 的价值是把运行时不确定性尽量前移到开发阶段，但它不能替代运行时校验。
类型设计应优先描述业务约束，而不是为了炫技使用复杂泛型。
遇到第三方输入、JSON、表单和 API 响应时，要结合类型收窄或 schema 校验。

在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。

实践检查清单

明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
最后用一句话总结取舍：它牺牲了什么，换来了什么。

自测问题

这个主题解决的核心问题是什么？
如果不用当前方案，还有哪些替代方案？代价是什么？
最容易出错的边界条件在哪里？
如何在代码、测试或监控中验证它真的可靠？

项目化应用场景

可以把这类知识放到一个前后端共享类型的项目里理解：API 返回 JSON，前端先用 schema 做运行时校验，再把校验后的数据交给 TypeScript 类型系统。类型可以帮助编辑器提示和编译期检查，但不能保证网络返回一定正确。好的类型设计应该表达业务约束，例如角色、状态、权限、请求参数和响应结构，而不是所有地方都写成 string 或 any。

常见误区：

把 TypeScript 类型当成运行时校验。
为了省事使用 any，导致错误延后到线上。
泛型过度复杂，让调用者难以理解。

目录