TypeScript条件类型为何在泛型继承场景下出现赋值错误？

我定义了一个条件类型，两侧分支的结果完全相同：

type Wut<T> = T extends number ? string | T : string | T

（这个类型没什么实际用处，我只是想搞清楚背后的原理。）

直接使用这个类型时一切正常：

const huh1: Wut<number> = 'huh'  // 正常
const huh2: Wut<object> = 'huh'  // 正常
const huh3: Wut<string> = 'huh'  // 正常
const huh4: Wut<number> = 22     // 正常

但在继承自其他泛型的场景中使用时，却出现了错误：

function hmmm<N extends number, S extends string>() {
    const huh1: Wut<N> = 'huh' // <- 类型“string”不能赋值给类型“Wut<T>”
    const huh2: Wut<N> = 22    // <- 类型“number”不能赋值给类型“Wut<T>”
    const huh3: Wut<S> = 'huh' // <- 类型“string”不能赋值给类型“Wut<T>”
}

问题原因 #

核心在于条件类型的延迟解析和泛型约束的不确定性：

• 当直接传入具体类型（比如number）时，TypeScript能立刻确定条件分支的结果，直接简化为string | number，所以赋值操作完全合法。
• 但当泛型参数是N extends number这种受约束的类型时，TypeScript无法在编译阶段确定N的具体子类型（可能是number本身，也可能是123这类字面量类型）。此时Wut<N>会被视为未解析的条件类型，TypeScript不会提前将其展开为string | N，而是采取保守检查策略，导致无法确认'huh'或22是否符合最终类型，从而抛出错误。

解决方法 #

既然条件类型的两个分支结果完全一致，完全可以直接简化为非条件类型：

type Wut<T> = string | T

这样无论在直接使用还是泛型约束场景下，TypeScript都能明确识别类型，赋值操作自然不会有问题。

如果一定要保留条件类型的写法（虽然没必要），也可以通过分布式条件类型的特性实现等价效果：

type Wut<T> = T extends any ? string | T : never

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