接口与泛型：TS复用利器

可视化演示

展示TypeScript接口如何定义对象形状契约，以及泛型如何实现参数化类型复用，切换模式查看接口实现与泛型实例化。

接口基础：一张菜品规格书

你走进一家讲究的川菜馆，服务员下单前会递给你一张印刷好的点菜单：菜名、价格、辣度，栏位清清楚楚。后厨出菜时，传菜员不是直接端上来，而是先拿这张菜单对一遍——菜名对得上、价格没标错、辣度标记存在，才放行。这张“菜品规格书”就是 TypeScript 里的接口：它不生产任何实际数据，只负责规定“一个对象应该长什么样”。

在 TypeScript 里，你声明一个 interface Dish，写出 name: string、price: number，就相当于跟编译器约定：凡是宣称自己是“一道菜”的对象，必须带 name 和 price 这两个字段，而且值的类型要对。实际写法很简单：

使用方式是把对象交给类型标注，例如 const d: Dish = {...}，编译器就会按规格书逐项验收。TypeScript 的类型系统是“结构化”的（structural typing）——它不看对象的出身，只看形状是否匹配：只要字段齐全、类型正确，哪怕对象字面量没有写 implements Dish，也照样通过检查。

所以接口最朴素的心法就是“先写规格书，再上菜”：把数据形状提前钉死，编译器才能在错误进入业务逻辑之前就把菜打回，这正是复用代码的第一块基石。

interface Dish {  name: string;  price: number;}

属性修饰：辣度可选，编号只读

菜单上不是每个格子都必须填。“辣度”一栏后面通常印着“可选”，你不勾，默认就是不辣；而菜单右上角那串“菜品编号”是印刷上去的，顾客不可能拿笔改掉。这两个生活细节，恰好对应接口的两类属性修饰符。

price?: number 中的问号表示“可选属性”——对象可以没有这个字段；readonly id: number 表示“只读属性”——对象创建的那一刻定下来，之后谁也不能改。两者约束的都是“字段的存在方式”，而不是字段的值本身：

可选属性让接口更宽容，适合“新菜还没定价”的真实场景；只读属性则适合“一旦生成就不该变”的数据，比如主键、创建时间。另外还有一个配套规则叫“多余属性检查”：用对象字面量直接给 Dish 赋值时，出现规格书上没写的字段会报错——就像你往菜单里塞一个不存在的“魔法加成”栏目，传菜员当场拒收。

下次写接口时问自己三个问题：这个字段一定能拿到吗？拿到之后还能改吗？有没有多余的字段混进来？答案写进修饰符里，规格书才真正严谨。

interface Dish {  readonly id: number;  name: string;  price?: number;}

接口继承：从基础套餐到豪华套餐

餐厅推出“豪华套餐”：它包含基础套餐的全部内容——前菜、主食、例汤一样不少，再额外加一份招牌甜品。如果用接口来写，我们当然不想把基础字段重新抄一遍，而是直接“继承”已有的规格书。这就是接口继承的由来。

SetMeal 自动拥有 name 和 price，还多一个 dessert 字段。继承还可以多个并行：interface Combo extends BaseDish, Drinkable {}，把两套规格合并成一套。这样公共字段只写一次，后续改价格字段的类型，所有子接口同步生效。

继承让“规格书”可以像套娃一样层层叠加，公共字段只写一次，变更时改一处即可——这正是“复用”二字的第一个具体体现。

interface BaseDish {  name: string;  price: number;} interface SetMeal extends BaseDish {  dessert: string;}

泛型函数：万能出餐窗口

后厨有个万能出餐窗口，贴着告示：“您点什么，我们就端什么。”牛肉进来端牛肉，豆腐进来端豆腐，流程完全一样，但结果永远是您点的那份食材——绝不掉包。这个“不挑食材的窗口”就是泛型函数。

<T> 是“类型参数”，可以理解为窗口上的占位标签。调用时 TypeScript 会根据实参自动推断 T：identity(42) 返回 number，identity('hi') 返回 string。如果换成 any 来写，返回值会变成 any，出了函数就再也分不清原来是牛肉还是豆腐，后续的类型检查全部失效。

泛型函数的价值正是窗口上那句告示的承诺：代码只写一遍，但“类型”这个客人点单时永远不被掉包，复用与安全同时到手。

function identity<T>(x: T): T {  return x;}

泛型类：一个保温箱走天下

后厨有一种通用保温箱，箱体就是箱体，放什么由你决定：放炖菜，取出来还是炖菜；放甜汤，取出来还是甜汤。类的逻辑也完全一样，只是里面装的“食材类型”不同。这就是泛型类。

实例化时指定具体类型：new Box<number>(42)，此后 get() 的返回值就是 number；new Box<string>('hi')，返回值就是 string。类的所有成员都能引用类名后的 <T>，相当于把“类型参数”从函数级提升到了类级，整个类的内部类型全部绑定在一个参数上。

泛型类把“箱体”与“内容”解耦：一套结构，任意类型，实例化时一拍即合——这是比函数更高一层的复用单元。

class Box<T> {  value: T;  constructor(value: T) {    this.value = value;  }  get(): T {    return this.value;  }}

泛型约束：只有能下锅的食材才准进厨房

后厨立了一条规矩：“只有能下锅的食材才允许进厨房。”什么叫能下锅？至少得能被处理——比如有“长度”、有“结构”这一类可操作属性。泛型约束就是在类型层面立同样的规矩：允许进入泛型函数的类型，必须满足某个形状要求。

T extends { length: number } 给 T 划了上限：只有带 length 字段的类型（字符串、数组）才准进来，数字直接被编译器拦在门外。还有一个更精细的写法 K extends keyof T：K 必须是 T 的属性名之一，用于安全地读写 T 的某个字段，写错属性名立刻报错。

约束不是限制自由，而是把“食材资格”提前说清：不合格的类型在编译期就被挡在厨房外，而不是运行时才在锅里闹出事故——这比运行时再犯错要省钱得多。

function longest<T extends { length: number }>(a: T, b: T): T {  return a.length >= b.length ? a : b;}

默认类型参数：不指定就默认猪肉

菜单上有些套餐旁边写着“默认猪肉”——你不特别说明，后厨就按猪肉备菜；你点名要牛肉，那就听你的。泛型里的默认类型参数就是这个“默认猪肉”，它让接口更友好：少写一点，也能正常工作。

使用 Pair 时不写尖括号，编译器自动代入默认类型 string；显式写 Pair<number> 时，以显式声明的为准，默认值只作兜底。这个特性和可选属性搭配使用非常顺手：既保持接口的灵活性，又避免调用方被迫写一堆尖括号。

默认参数让调用方少写一大串尖括号，同时保留灵活性——这是“贴心设计”的典型，也是接口与泛型组合时常用的减负技巧。

interface Pair<T = string> {  first: T;  second: T;} const p1: Pair = { first: 'a', second: 'b' };      // T 默认 stringconst p2: Pair<number> = { first: 1, second: 2 }; // 显式传入 number

实战应用：从规格书到出餐流水线

后厨的终极形态是一套标准作业流程：规格书钉死每道菜的形态，万能窗口让同一套流程适配不同食材。两者合体，就是一条不挑菜、不出错的出餐流水线。在真实项目中，最常见的组合就是“接口定义形状 + 泛型承载类型”。

调用 fetchData<User>(url) 之后，res.data 直接被推断为 User，业务代码里不需要一堆 as 强转。通用表格组件、状态管理 store、AI 接口封装，全是这套“契约 + 泛型”的典型应用：接口是外层的固定骨架，泛型是留给业务数据的槽位。

至此整条流水线打通：接口管“长什么样”，泛型管“装得下什么”，复用与安全兼得——这就是 TypeScript 留给工程师最趁手的两件家伙。

interface ApiResponse<T> {  code: number;  data: T;  msg: string;} async function fetchData<T>(url: string): Promise<ApiResponse<T>> {  const res = await fetch(url);  return res.json() as Promise<ApiResponse<T>>;}

AI 应用场景

Python 演示

from dataclasses import dataclassfrom typing import Generic, Optional, Protocol, TypeVar  class Lengthable(Protocol):    def __len__(self) -> int:        ...  T = TypeVar("T")U = TypeVar("U", bound=Lengthable)  @dataclassclass Dish:    # 类似 TS 的 interface Dish: name/price/spicy?    name: str    price: float    spicy: Optional[bool] = None  def longest(a: U, b: U) -> U:    # 泛型约束: 只有具备 __len__ 的类型才能进入    return a if len(a) >= len(b) else b  class Box(Generic[T]):    # 类似 TS 的 class Box<T>: value 类型与实例绑定    def __init__(self, value: T) -> None:        self.value = value     def get(self) -> T:        return self.value     def set(self, value: T) -> None:        self.value = value  if __name__ == "__main__":    dish = Dish(name="麻婆豆腐", price=28.0, spicy=True)    print(dish)     str_box: Box[str] = Box("hello")    int_box: Box[int] = Box(42)    print(str_box.get(), int_box.get(), type(int_box.get()).__name__)    print(longest("interface", "generic"))

1. @dataclass class Dish像 TS 的 interface 一样声明对象的字段形状，spicy 带默认值模拟可选属性
2. class Box(Generic[T])对应 TS 的泛型类 Box<T>，实例的 value 类型与声明时绑定
3. str_box: Box[str] = Box("hello")实例化时指定具体类型，相当于 new Box<string>('hello')
4. TypeVar("U", bound=Lengthable)模拟泛型约束 T extends { length: number }，只有可求长度的类型才能传入
5. longest("interface", "generic")传入两个字符串，返回较长者，类型安全地验证了约束逻辑

常见误区

面试题