TypeScript泛型参数联合类型推断疑问：为何e4为string而非String、e5为String而非string？

我们先拆解问题核心：StringConstructor同时具备构造签名（new String(...)返回String对象）和调用签名（String(...)返回原始string值），TypeScript在类型推断时会根据你定义的联合类型分支规则，选择最符合逻辑的R值。

一、为什么e4的推断结果是string？ #

先看PropConstructor4的定义：

type PropConstructor4<T = any> = { new(...args: any[]): (T & object) } | { (): T }

这个类型是两个分支的联合：

1. 分支1：构造函数，返回值必须是T & object（意味着T必须是对象类型，因为& object会过滤掉原始类型）
2. 分支2：普通函数，返回值是T

当我们用StringConstructor extends PropConstructor4<infer R>推断R时，TypeScript会检查StringConstructor能否匹配任意一个分支：

• 对于分支1：StringConstructor的构造签名返回String对象，要满足T & object = String，T只能是String（因为String & object就是String本身）。但R=String时，分支2要求普通函数返回String，虽然String()返回的原始string可以装箱为String对象，但TypeScript还有更精准的匹配选项。
• 对于分支2：StringConstructor的调用签名直接返回原始string，完全匹配(): T的要求，此时T=string。

这里的关键是：分支1的T & object限制了T必须是对象类型，原始string不符合这个要求，所以R=string只能匹配分支2，但它完全贴合调用签名的原始返回值，不需要依赖装箱转换；而R=String虽能匹配两个分支，但TypeScript会优先选择最精准、无额外转换的推断结果，也就是string。

结合你的测试用例：

• a4只匹配分支1，所以推断出构造函数返回的String对象类型
• c4只匹配分支2，所以推断出调用函数返回的原始string类型
• e4是联合分支，TypeScript最终选择了最精准的string。

二、为什么e5的推断结果是String？ #

再看PropConstructor5的定义：

type PropConstructor5<T = any> = { new(...args: any[]): T } | { (): T }

这个类型去掉了分支1的& object限制，两个分支都直接要求返回值为T。

此时TypeScript推断R时，会找一个能让StringConstructor匹配尽可能多分支的类型：

• 如果R=string：分支1要求构造函数返回string，但new String()返回的是String对象，无法直接赋值给原始string类型，所以分支1不匹配，只有分支2能匹配。
• 如果R=String：分支1完全匹配（构造函数返回String），分支2也匹配（String()返回的string可以自动装箱为String对象，符合(): String的要求）。

TypeScript在推断泛型时会优先选择能覆盖更多分支的类型，所以R=String是更合理的选择——它能让整个联合类型都匹配，而R=string只能满足一个分支。

总结一下：

• 当分支有& object限制时，TypeScript优先选择贴合原始类型的string（对象类型分支无法用原始类型满足）
• 当没有& object限制时，TypeScript选择能覆盖构造+调用两个签名的String类型

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