为何泛型约束中额外空元组会改变TypeScript的类型推断？

先看两个示例代码的差异：

第一个函数无法编译：

function foo<T extends number[]>(
  x: T,
  y: (T["length"] extends 2 ? string : never)): T {
  return x;
}

foo([1,2], "test"); // 编译错误：类型"test"不能赋值给类型never

原因是[1,2]被推断为number[]（任意长度的数字数组），其length是number类型，并不固定为2，因此y的类型是never，无法传入字符串。

第二个函数却能正常运行：

function bar<T extends [] | number[]>(
  x: T,
  y: (T["length"] extends 2 ? string : never)): T {
  return x;
}

bar([1,2], "test"); // 正常编译

这里[1,2]被推断为[number, number]（长度固定为2的元组），满足T["length"] extends 2，因此y的类型是string，匹配传入的参数。

背后的核心规则 #

这种差异源于TypeScript对数组字面量的泛型推断策略，关键在于约束是单一类型还是联合类型：

• 当约束是单一数组类型（如number[]）：
  TypeScript会优先将数组字面量推断为宽泛的数组类型（而非元组），因为number[]代表任意长度的数字数组，编译器默认选择更通用的类型，除非有显式的元组注解（比如as const或明确的元组类型声明）。

• 当约束是包含元组的联合类型（如[] | number[]）：
  编译器会触发更细致的类型匹配逻辑：它会尝试为数组字面量找到联合类型中最具体的匹配项。虽然[]是空元组，和[1,2]不匹配，但联合类型的存在会促使编译器考虑“是否可以推断为更具体的元组类型”——而元组类型本身是number[]的子类型，同时能满足T["length"] extends 2的精确长度约束。因此编译器最终选择[number, number]作为T的推断结果，让代码符合类型要求。

额外验证 #

如果调用bar([1], "test")，会触发编译错误：此时[1]被推断为[number]（长度为1的元组），T["length"] extends 2不成立，y的类型变为never，无法传入字符串。这进一步证明了编译器确实在联合约束下优先推断元组类型。

内容的提问来源于stack exchange，提问作者Lai Yu-Hsuan