泛型编程高级技巧：让 TypeScript 类型系统真正服务抽象与复用

很多开发者学到 TypeScript 泛型时，最先接触的是 Array<T>、Promise<T> 这类基础形式。但真正进入项目复杂区之后，问题会变成另一种样子：

如何让输入和输出自动关联
如何让配置项影响返回值结构
如何避免复用逻辑牺牲调用体验

泛型编程高级技巧要解决的，正是这些“抽象已经出现，但类型还没跟上”的问题。

泛型的重点是表达关系，不是增加复杂度

很多泛型写法之所以难维护，不是因为用了高级语法，而是因为它没有服务真实关系。

更稳的判断标准是：类型是否在表达输入、输出和约束之间的关系。

function pick<T, K extends keyof T>(source: T, keys: K[]): Pick<T, K> {
  const result = {} as Pick<T, K>

  for (const key of keys) {
    result[key] = source[key]
  }

  return result
}

这里的重点不是语法本身，而是 K 与 T 的关系被完整表达了出来。

优先用约束和默认值控制泛型边界

高级泛型最容易失控的地方，在于“什么都能传进来”。一旦约束不足，推断会变宽，调用体验也会变差。

interface ApiResponse<TData = unknown, TMeta = Record<string, never>> {
  data: TData
  meta: TMeta
  success: boolean
}

这类写法的价值在于：

默认值降低心智负担
约束明确返回结构
后续扩展时不会破坏已有调用

条件类型适合描述“分支返回”，但不要滥用

当函数或配置存在明显分支时，条件类型很有价值。

type Result<T extends 'summary' | 'detail'> = T extends 'summary'
  ? { id: string; title: string }
  : { id: string; title: string; content: string; updatedAt: string }

function getArticle<T extends 'summary' | 'detail'>(mode: T): Result<T> {
  throw new Error('implementation omitted')
}

但条件类型一旦层层嵌套、再叠加映射和递归，团队理解成本会快速上升。更好的做法，是只在“确实需要表达分支关系”的地方使用它。