背景与问题界定

条件类型是 TypeScript 类型系统中最为强大也最为复杂的特性之一。它的核心语法 T extends U ? X : Y 看似简单，但在实际的工程应用中却极其容易踩坑——特别是当条件类型遇到联合类型时，TypeScript 会执行**分发（Distributive）**行为，将联合类型的每个分支分别代入条件判断。许多开发者在编写高级类型工具时，因为不理解分发机制而得到意外的类型结果。更复杂的是 infer 关键字——它允许在 extends 子句中声明类型变量，用于在模式匹配中捕获类型的某个部分。从提取函数返回类型到解构 Promise 的包裹类型，infer 是类型体操的基石。理解这些机制并将其系统化，是项目从 “能用 TypeScript” 进化到 “充分发挥类型系统能力” 的关键一步。

目标拆解与工程约束

  • 条件类型的可预测性：任何条件类型表达式在给定相同输入时，必须输出确定且唯一的类型，不受上下文影响。
  • 分发的显式控制：当需要禁用分发行为时，通过 [T] extends [U] 的元组包裹或使用 T & {} 明确表达意图。
  • infer 的单一来源：在一个条件类型中，同名 infer 变量只允许出现一次，多次出现会导致类型推导的不确定行为。
  • 类型工具的可读性：复杂的条件类型应分解为多个命名的中间类型，每个类型附带 JSDoc 说明其计算逻辑。

方案设计

条件类型的核心机制围绕三个概念展开：分发条件类型（Distributive Conditional Types）、类型推断（infer） 和 递归条件类型（Recursive Conditional Types）。

分发是 TypeScript 条件类型的默认行为：当 T 是一个联合类型（如 string | number）时，T extends U ? X : Y 会被展开为 (string extends U ? X : Y) | (number extends U ? X : Y)。这意味着我们可以像操作普通数据一样操作类型。一个经典的应用是过滤联合类型中的某些成员：

type ExtractString<T> = T extends string ? T : never
type Result = ExtractString<string | number | boolean | 'hello'>
// Result = string | 'hello'（never 在联合类型中被自动消除）

通过禁用分发机制，我们可以实现非期望分布的场景。例如检查一个类型是否是纯联合类型而不展开它：

type IsUnion<T, U = T> =
  T extends any
    ? [U] extends [T]
      ? false
      : true
    : never

infer 关键字是条件类型中的模式匹配利器。它允许我们"拆解"一个复杂的类型结构，提取其内部类型。最经典的例子是从 Promise 中提取值的类型：

type Unwrap<T> = T extends Promise<infer U> ? U : T
type Unwrapped = Unwrap<Promise<string>>  // string

infer 的威力在于协变位置的多重 infer 和 逆变位置的分发 infer。在协变位置（如函数返回类型），多个候选类型会被合并为联合类型；在逆变位置（如函数参数类型），多个候选类型会被交叉为交叉类型。利用这个特性，我们可以将联合类型转换为交叉类型：

type UnionToIntersection<U> =
  (U extends any ? (k: U) => void : never) extends
    (k: infer I) => void ? I : never

递归条件类型则用于处理递归数据结构，如 JSON 类型、深层可选的类型展开等。TypeScript 4.1 引入了尾递归优化的条件类型，使得深度为 50 层左右的递归类型不会导致编译器崩溃。

在实际工程中，我们将这些技术组合成实用的类型工具。例如定义一个从 GraphQL schema 自动推导查询参数的泛型类型，或者构建类型安全的 Redux action creator 的类型映射。

实施路径与关键决策

  • 建立类型工具文档：每个条件类型工具附带至少一个输入示例和一个输出示例，明确标注分发的启用或禁用状态。
  • 编写类型级单元测试：使用 expect-type 或 tsd 断言类型工具的输出是否符合预期，每个 infer 分支单独测试。
  • CI 中纳入类型复杂度检查：使用 tsc --noEmit --diagnostics 监控类型检查耗时，单个条件类型超过 20 层嵌套时发出告警。
  • 在 Code Review 中标记危险模式：如 T extends any 和 never 的组合需要特别审查，确认分发行为是预期的。

验证指标与可持续迭代

类型检查时长保持在与改造前相同的量级（±10%），无新增的 any 或 as any 逃脱类型检查的现象。类型工具的测试覆盖率达 100%，包括正常输入、边界输入（如 never、unknown、any）和联合类型输入。后续迭代方向：探索 TypeScript 5.x 的 const 类型参数对模板字面量类型的增强、satisfies 关键字在复杂条件类型场景下的简化能力。

工程落地思考

条件类型的强大来自于它对类型空间的代数运算能力——我们可以像操作运行时数据一样组合、变换和推导类型。这种能力在很多场景下是无可替代的：当你需要编写一个通用的 API 封装层、一个类型安全的事件系统或一个类型推导的 ORM 时，条件类型和 infer 就是你的底层数学工具。但同样必须警惕的是，条件类型越强大，越容易写出让人困惑的类型。一个好的原则是：类型工具的输入和输出应该是直观的，团队中 80% 的人可以不看实现就猜到类型的用途。如果做不到这一点，复杂的类型工具带来的维护成本可能超过它带来的收益。