在TypeScript的类型运算中，函数参数和联合类型碰到一起时，经常产生一些容易混淆的结果。一个典型的问题是：为什么一个接收 string | number 参数的函数，在条件类型里会被当成两个分别接收 string 和 number 的函数来处理？这里涉及两种类型系统机制：函数参数位置的逆变兼容，以及条件类型对裸类型参数的分配。两者看似独立，但在类型工具设计中经常交织出现。本文先把函数参数的兼容性规则梳理清楚，再解释联合类型分配性的触发条件和抑制方法，最后通过几个实际类型工具展示如何利用或规避分配性。
一、函数参数逆变：联合类型在兼容性中的基础行为
函数类型之间的兼容性遵循结构化子类型规则。在开启 strictFunctionTypes 选项后，函数参数按照逆变位置检查：如果源函数类型要赋给目标函数类型，那么目标函数的参数类型必须能够赋给源函数的参数类型。这个方向与返回值相反，返回值是协变。例如有一个函数接收 string | number，它可以安全地赋给一个只接收 string 的函数变量，因为调用方只会传入 string，而 string 显然属于 string | number。
type Handler = (value: string | number) => void; declare const handler: Handler; // string 可以赋给 string | number，因此参数逆变成立 const stringOnly: (value: string) => void = handler;
反过来则不行。一个只接收 string 的函数不能赋给接收 string | number 的函数，因为目标调用方可能传入 number，而源函数无法处理 number 类型。这种兼容性判断中的联合类型是作为一个整体参与的：TypeScript 不会把 string | number 拆成两个分支分别比较，而是检查目标参数类型是否可赋给源参数类型的整体联合类型。
理解这一点是后续讨论的基础。因为函数参数位置的联合类型在普通赋值、参数传递中不会自动分配，分配性只出现在条件类型对裸类型参数的判断中。下一节重点分析这个分配过程，以及它如何反过来影响函数类型的结果形态。
二、条件类型分配性：联合类型被拆开处理
TypeScript 的条件类型语法为 T extends U ? X : Y。当这里的 T 是一个裸类型参数，并且该类型参数被实例化为联合类型时，条件类型会发生分配：检查不再针对整个联合类型执行一次，而是针对联合类型中的每个成员分别执行，最后把每个分支的结果合并成一个新的联合类型。这个特性被称为分配条件类型。
type ToArray<T> = T extends any ? T[] : never; type R1 = ToArray<string | number>; // 得到 string[] | number[]
上面的 ToArray<string | number> 并没有生成 (string | number)[]，而是生成了 string[] | number[]。原因在于 T 在 extends 左侧是裸类型参数，TypeScript 将其拆分为 string 和 number 两个分支，分别计算 string extends any ? string[] : never 和 number extends any ? number[] : never，再将结果联合起来。
这个分配特性与函数参数结合后，会出现一种特殊的函数类型拆分。例如定义一个类型别名，把联合类型映射成一组函数类型：
type SplitParam<U> = U extends any ? (arg: U) => void : never; type SplitFn = SplitParam<string | number>; // 结果是 ((arg: string) => void) | ((arg: number) => void)
这里 U 被分配后，string 和 number 分别生成了各自的函数类型，最后得到函数联合。这个结果与直接写 (arg: string | number) => void 完全不同。前者是两个函数的联合，后者是一个函数接收联合参数。这种差异会直接影响后续的类型兼容性判断，也是很多类型工具出错的地方。
三、分配性的触发条件与抑制方式
分配性并不是对任何联合类型都生效。它要求条件类型中的被检查类型必须是裸类型参数。裸类型参数指的是直接写在 extends 左侧的类型参数本身，没有被数组、元组、对象等包装。例如 T extends any 中的 T 是裸的，而 [T] extends [any] 中的 T 被数组包裹，就不再满足分配条件。
type ToArrayNonDist<T> = [T] extends [any] ? T[] : never; type R2 = ToArrayNonDist<string | number>; // 结果是 (string | number)[]
通过把 T 和 any 分别放进元组，条件类型检查的对象从 T 变为 [T]。此时 [T] 不是裸类型参数，TypeScript 不会对 T 进行分配，因此得到的是一个整体的数组类型。这种技巧在需要保留联合类型完整性时非常实用，例如希望把整个参数联合类型当作一个单元处理时，可以避免默认的分配行为。
除了数组包裹，还可以利用函数参数的逆变位置来改变分配行为。函数参数本身并不会自动触发分配，但把裸类型参数放入函数参数位置后再进行条件判断，分配的对象可能发生变化。例如在 T extends (arg: infer P) => any ? P : never 中，T 作为裸类型参数仍然会分配；但如果设计类型工具时先构造出函数类型再提取参数，就能控制分配发生在哪一层。理解这一点需要结合实际场景，下一节通过实用工具进一步说明。
四、函数参数场景中的分配性陷阱与实用工具
在编写类型工具时，联合类型的分配性既能带来便利，也容易造成逻辑偏差。一个常见需求是判断一个类型是否为联合类型。借助分配性可以实现：
type IsUnion<T, U = T> = T extends any ? [U] extends [T] ? false : true : never; type IsStringNumberUnion = IsUnion<string | number>; // true type IsString = IsUnion<string>; // false
这个工具利用了两个 T 的不同角色：外层 T extends any 触发分配，内层 [U] extends [T] 用数组包裹避免二次分配。当 T 分配为 string 时，U 是原始联合 string | number，比较 [string | number] 是否 extends [string] 为 false，因此返回 true。如果 T 本身不是联合类型，不会发生分配，外层只执行一次，内层比较相同类型返回 false。这个工具展示了分配性与函数参数无关，但同样的模式可以用于处理函数参数类型。
再来看函数参数被分配后产生的类型兼容性差异。假设我们有一个函数联合 ((arg: string) => void) | ((arg: number) => void) 和一个联合参数函数 (arg: string | number) => void，它们之间并不是完全互相赋值的关系：
declare const fnUnion: ((arg: string) => void) | ((arg: number) => void); declare const fnCombined: (arg: string | number) => void; const a: (arg: string | number) => void = fnUnion; // 错误 const b: ((arg: string) => void) | ((arg: number) => void) = fnCombined; // 正确
函数联合不能赋给联合参数函数，是因为函数联合的每个成员都要求更窄的参数类型，无法满足联合参数函数在逆变位置的检查；而联合参数函数可以赋给函数联合，是因为它能够处理任意成员对应的参数类型。理解这种方向差异，有助于在设计回调类型、事件处理器类型时做出正确选择。如果希望一个函数能处理多种参数类型，直接使用联合参数更合适；如果希望保留不同参数类型的独立处理逻辑，则函数联合可能更符合预期，但要清楚它不能赋给联合参数的函数类型。
总结来说，TypeScript 中联合类型的分配性主要发生在条件类型对裸类型参数的判断中，函数参数位置本身不会触发分配，但函数参数联合类型一旦被传入条件类型，就可能被拆成多个函数类型。掌握分配性的触发条件及抑制方法，能够帮助你在类型兼容性判断、类型工具设计中避免意外结果，并有意识地利用这一特性构建更精确的类型逻辑。
TypeScript类型兼容性联合类型分配性修改时间：2026-10-03 17:29:08