TypeScript实战：泛型约束与类型体操在前端工程化中的应用

TypeScript的工程价值在中等规模以上的前端项目里才完全显现：团队协作时接口即契约、重构时编译器兜底、库作者能给用户准确的提示。类型系统用得好，注释量降一半，运行时错误提前到编译期。泛型与类型体操是进阶核心，掌握了才能写出真正可复用的工具函数和组件，而不是到处都是any。

泛型基础：约束与内置工具类型组合

泛型约束通过extends限定类型的适用范围，把”函数接受任意类型”变成”函数接受带length属性的类型”。内置工具类型Pick、Omit、Partial、Required覆盖绝大多数业务场景，先熟它们再上手自己写递归类型。报错信息难看懂是常态，把复杂类型拆成一步步临时变量验证，比一次性写完更稳妥。

// 泛型约束 + 工具类型组合示例
interface HasLength {
  length: number
}
function lastOf<T extends HasLength>(arr: T): T[number] {
  return arr[arr.length - 1]
}
type User = { id: number; name: string; age: number }
type UserPreview = Pick<User, 'id' | 'name'>   // { id: number; name: string }
type UserWithoutAge = Omit<User, 'age'>       // { id: number; name: string }

类型体操实战：条件类型与infer推导

条件类型根据输入类型输出不同类型，infer用于在类型里做”取中间部分”的推导，是类型体操的地基。典型场景：从函数类型提取参数、从数组取元素类型、把联合类型转成对象。递归类型用于深度readonly或深层可选，注意限制深度，递归过深会直接报类型实例化过深。

// 提取函数返回类型：infer 用法
type MyReturnType<T> =
  T extends (...args: any[]) => infer R ? R : never
type R = MyReturnType<() => string[]>  // string[]

// 递归深度Readonly
type DeepReadonly<T> = {
  readonly [K in keyof T]: T[K] extends object ? DeepReadonly<T[K]> : T[K]
}

组件库设计中的类型落点与团队规范

组件库是类型收益最大的场景：给组件写清Props、定义回调类型、对外暴露Ref实例类型，使用者靠编辑器提示就能少翻文档。团队规范上建议禁止裸any，公共类型统一收进types.d.ts。组件泛型建议控制在1到2个，参数类型叠参数类型，维护体验会明显下降。Vue3的defineProps泛型与React泛型组件在思路上一一对应，跨端小程序与Flutter场景里共享类型定义能避免两端各写一遍DTS。

前端工程化项目里，把”类型是否严谨”纳入code review检查项，和逻辑审查同等对待。类型体操不是炫技，最终目标永远是：改一处类型，编译器替团队找出所有受影响的调用点。