TypeScript 如何让联合元组类型的常规函数参数具备完整校验能力

两种写法的校验差异，本质是泛型的推断逻辑存在核心区别：

• 剩余参数实现的foo函数，泛型T的推断来源是整个入参组成的元组结构：TS会将调用时传入的所有参数打包为一个整体元组，直接推断该元组的类型为T，再检查T是否满足extends KnownPair的约束。整个校验过程是元组层面的整体匹配，两个参数的配对关系从推断阶段就被绑定，混搭参数生成的元组本身不符合KnownPair类型，因此会被准确拦截。
• 拆分T[0]、T[1]实现的bar函数，泛型T的推断来源是每个独立参数的反向类型推导：TS在泛型推断时，会针对每个参数位置单独收集T的候选值：
  1. 遇到第一个参数"dog"，为满足a: T[0]的类型要求，会收集候选T = ["dog", "paws"]
  2. 遇到第二个参数"scales"，为满足b: T[1]的类型要求，会收集候选T = ["fish", "scales"]
  3. 最后TS会将收集到的多个候选合并为一个兼容所有入参的T值——这个合并后的T的索引0可以兼容"dog"，索引1可以兼容"scales"，完全满足两个参数的类型要求，因此不会触发任何报错。

这种独立收集泛型候选的行为，是TS的通用推断逻辑：

function identity<T>(a: T, b: T) {}
// 传入不同类型的值不会报错，因为TS会将T推断为string | number，兼容两个参数
identity(1, "string");

多个参数位置引用同一个泛型时，TS不会强制要求这些位置推导出的T值完全一致，最终会通过合并候选为联合类型实现参数兼容，自然就丢失了两个参数的配对约束。

关于显式指定泛型时的拦截误区：
你观察到的bar<["dog","scales"]>("dog", "scales")被拦截的现象，本质是["dog","scales"]本身不满足T extends KnownPair的泛型约束，TS在泛型约束校验环节就抛出了错误，和a、b的配对校验逻辑没有关系，不代表推断场景下的配对约束可以正常生效。

要实现和剩余参数版本一致的校验能力，同时保留两个独立形参的写法，核心思路是跳过会拆分泛型的推断逻辑，将合法的配对关系直接编码为函数的签名约束。最简洁的实现是通过条件类型将联合元组分拆为对应的独立参数函数：

type KnownPair = ["dog", "paws"] | ["fish", "scales"];

// 对联合元组的每个分支，生成对应接收两个独立参数的函数类型
type PairValidator = KnownPair extends infer Pair
  ? Pair extends [infer First, infer Second]
    ? (first: First, second: Second) => void
    : never
  : never;

// 按上述类型定义独立参数的函数
const bar: PairValidator = (first, second) => {
  console.log(`${first} has ${second}`);
}

// 校验效果和剩余参数版本完全一致
bar("dog", "paws"); // 正常通过
bar("fish", "scales"); // 正常通过
bar("dog", "scales"); // 直接报错，无匹配的函数签名

如果不想依赖条件类型生成签名，也可以手动为每个合法配对写函数重载，效果完全等价：

function bar(a: "dog", b: "paws"): void;
function bar(a: "fish", b: "scales"): void;
// 实现签名仅用于函数逻辑，不参与外部调用的类型匹配
function bar(a: string, b: string): void {
  console.log(`${a} has ${b}`);
}

上述两种写法的本质，是将合法的参数配对关系直接编码为TS可匹配的函数签名，调用时TS会逐一匹配所有合法签名，只有完全匹配某一个配对关系时才会放行，从根本上避免了泛型独立推断导致的配对关系丢失问题。

内容的提问来源于stack exchange，提问作者jrr