TypeScript 的类型系统远不止于给变量加上 :string 或 :number。当你把类型本身当作一门函数式编程语言来使用时，便进入了类型体操的领域。本文将从实际需求出发，系统梳理 TypeScript 类型层面的高级工具，帮助你在不引入运行时开销的前提下，把类型安全推到极限。
类型即计算
类型层编程的核心思想是：类型系统本身是一台可执行的抽象机器。我们可以在类型层面进行遍历、条件判断、字符串拼接和递归调用。所有类型体操代码在编译后都会完全擦除，零运行时成本。
// 类型层面加法器（递归递减实现）
type Add<A extends number, B extends number> = A extends 0 ? B
: B extends 0 ? A
: Add<Subtract<A, 1>, Add<1, B>>;
虽然上面的数值运算在实际项目中极少用到，但这种递归思维模式贯穿了所有高级类型工具的设计。
映射类型：Partial、Required、Readonly 的实现
TypeScript 内置的映射类型可以批量转换对象属性的修饰符。理解其底层实现是掌握类型体操的第一步。
type Partial<T> = {
[P in keyof T]?: T[P];
};
type Required<T> = {
[P in keyof T]-?: T[P];
};
type Readonly<T> = {
readonly [P in keyof T]: T[P];
};
-? 语法用于移除可选修饰符，readonly 前缀则增加只读标记。基于相同的映射原理，我们可以自行组合出更强大的工具：
// 只将所有值类型为函数的键设为可选
type OptionalFunctions<T> = {
[P in keyof T]: T[P] extends (...args: any[]) => any ? T[P] | undefined : T[P]
};
Record<K, T>、Pick<T, K>、Omit<T, K> 也都是映射类型的变体：
type Record<K extends keyof any, T> = {
[P in K]: T;
};
type Pick<T, K extends keyof T> = {
[P in K]: T[P];
};
type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;
Exclude 本身是一个条件类型，这说明映射类型与条件类型常常需要配合使用。
条件类型：extends、infer 与分布式展开
条件类型的语法非常精简：T extends U ? X : Y。它的威力在于可以在分支中对类型做进一步拆解。
infer 关键字：类型层面的模式匹配
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : never;
type Parameters<T> = T extends (...args: infer P) => any ? P : never;
type First<T extends any[]> = T extends [infer H, ...any[]] ? H : never;
type Last<T extends any[]> = T extends [...any[], infer L] ? L : never;
infer 就像类型层面的正则捕获组，只要 T 的结构能匹配 extends 右侧的模式，infer 绑定的变量就能在 ? 后的分支中使用。
分布式条件类型
当条件类型的被检查类型是一个裸类型参数时，TypeScript 会自动将其展开为联合类型的每个成员分别判断：
type ToArray<T> = T extends any ? T[] : never;
// string | number => string[] | number[]
type Result = ToArray<string | number>;
如果你不希望触发分布式行为，可以用方括号包裹类型参数：
type NonDistributiveArray<T> = [T] extends [any] ? T[] : never;
// (string | number)[]
type Result = NonDistributiveArray<string | number>;
这在编写工具类型时需要格外注意，错误的展开逻辑会导致意料之外的联合数组类型。
模板字面量类型：类型层面的字符串处理
模板字面量类型允许我们在类型层面拼接和拆分字符串，对于派生事件名、CSS 变量名、API 路由等场景极其实用。
type EventName<T extends string> = `on${Capitalize<T>}`;
type ClickEvent = EventName<'click'>; // "onClick"
type HttpMethod = 'get' | 'post' | 'put' | 'delete';
type Endpoint<T extends HttpMethod, P extends string> = `/${T}/${P}`;
配合 infer 和递归，模板字面量类型还能实现字符串的分割和转换：
type CamelCase<S extends string> =
S extends `${infer L}_${infer R}`
? `${Lowercase<L>}${Capitalize<CamelCase<R>>}`
: Lowercase<S>;
// "userName"
type Example = CamelCase<'user_name'>;
如果想实现 Getters 类型，将对象所有键转换成 getXxx 方法，结合映射类型和模板字面量即可：
type Getters<T> = {
[K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};
这里使用了 TypeScript 4.1 引入的键重映射（as 子句）。string & K 的作用是过滤掉 symbol 类型的键，因为模板字面量要求传入字符串类型。
递归类型：JSON、DeepReadonly 与 DeepPartial
对象的嵌套层级通常是未知且无限的，此时递归类型就派上了用场。
type JSONValue =
| string
| number
| boolean
| null
| JSONObject
| JSONArray;
interface JSONObject {
[K: string]: JSONValue;
}
interface JSONArray extends Array<JSONValue> {}
这个经典的 JSON 类型定义展示了递归在类型系统中的应用方式。同样的模式可以用于构建深度工具类型：
type DeepReadonly<T> = {
readonly [K in keyof T]: T[K] extends object
? T[K] extends (...args: any[]) => any
? T[K]
: DeepReadonly<T[K]>
: T[K];
};
type DeepPartial<T> = {
[P in keyof T]?: T[P] extends object ? DeepPartial<T[P]> : T[P];
};
type DeepRequired<T> = {
[P in keyof T]-?: T[P] extends object | undefined ? DeepRequired<T[P]> : T[P];
};
注意 DeepReadonly 中对函数的特殊处理：函数也是 object 的子类型，但我们通常不希望把方法也递归变成只读对象。这种特殊分支在递归类型中非常常见。
类型挑战中的实用模式
GitHub 上的 type-challenges 仓库收集了大量来自真实场景的类型难题。以下是几个高频出现且在生产代码中真正有用的模式。
TupleToUnion
将元组转换为联合类型，用于从常量数组派生类型：
type TupleToUnion<T extends readonly any[]> = T[number];
const colors = ['red', 'green', 'blue'] as const;
type Color = TupleToUnion<typeof colors>; // "red" | "green" | "blue"
UnionToIntersection
将联合类型转为交叉类型，常用于合并多个接口：
type UnionToIntersection<U> =
(U extends any ? (x: U) => void : never) extends (x: infer I) => void
? I
: never;
这个实现巧妙地利用了函数参数位置的逆变性，是条件类型与函数类型结合的经典案例。
Alike（判断两类型是否完全等价）
type Alike<X, Y> = (<T>() => T extends X ? 1 : 2) extends
(<T>() => T extends Y ? 1 : 2) ? true : false;
这个定义看起来晦涩，但它的核心思想是用泛型函数的外层包裹来阻止分布式条件类型的自动展开，从而实现严格的类型等价判断。
避免类型复杂度陷阱
高级类型虽然强大，但并非所有地方都适合堆砌类型体操。以下是一些实践建议：
优先保证可读性：如果一段类型代码需要超过 30 秒才能看懂，说明它可能需要重构。type MyType = ... 的另一端往往是需要维护的同事或三个月后的你自己。
在边界处做类型约束，内部使用宽松类型：对公共 API 的入参和返回值施加严格的类型，内部实现可以适当使用 any 或 unknown 配合运行时断言，避免过深的类型嵌套。
不要试图在类型层实现所有逻辑：类型系统图灵完备不假，但递归深度限制（默认 50 层）和编译性能问题会让你在大型项目中付出代价。数值运算、字符串复杂处理等，运行时解决通常更合适。
为复杂类型配备文档和测试：用 // @ts-expect-error 或 // @ts-ignore 的测试文件验证工具类型的边界行为，确保重构时不会破坏既有契约。
结语
TypeScript 的类型系统赋予前端工程一种独特的静态保证能力。从映射类型的批量转换，到条件类型的模式匹配，再到模板字面量的字符串推导，这些工具让开发者可以在编译期构建出严密的类型防护网。掌握它们不是为了炫技，而是为了在团队协作中提供更清晰、更安全的接口契约。合理使用高级类型，平衡安全与可维护性，才是类型体操的真正意义。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。