如何预测TypeScript的`type instantiation too deep`错误及递归差异

需求背景 #

我在学习TypeScript类型系统时，参与了Type Challenges中的CapitalizeWords类型挑战，要求将字符串中每个单词的首字母大写，示例如下：

type capitalized = CapitalizeWords<'hello world, my friends'> // 预期结果：'Hello World, My Friends'

首次实现及问题 #

我写出的第一版实现代码如下：

type CapitalizeWords<S extends string, C extends boolean = true> = 
    S extends `${infer A}${infer B}`
    ? Lowercase<A> extends Uppercase<A>
        ? `${A}${CapitalizeWords<B, true>}` 
        : C extends true 
            ? `${Uppercase<A>}${CapitalizeWords<B, false>}` 
            : `${A}${CapitalizeWords<B, false>}`
    : S

这个实现能处理短字符串（比如hello world），但遇到长字符串（如aa!bb@cc#dd$ee%ff^gg&hh*ii(jj)kk_ll+mm{nn}oo|pp🤣qq）时，会触发type instantiation too deep and possibly infinite错误。

优化后的实现 #

后来借助参考完成了第二版实现，代码如下：

type CapitalizeWords<S extends string, W extends string = ""> =
    S extends `${infer A}${infer B}`
    ? Lowercase<A> extends Uppercase<A>
        ? `${Capitalize<W>}${A}${CapitalizeWords<B>}`
        : CapitalizeWords<B, `${W}${A}`>
    : Capitalize<W>

这个版本可以处理上述长字符串，但我有两个疑问：

1. 两种实现看起来都是逐字符递归，为什么结果差异这么大？
2. 长到一定程度的字符串会不会让第二版也报错？怎么预测触发错误的条件和递归安全上限？

问题解析 #

两种递归的本质差异 #

虽然两者都是逐字符递归，但类型系统处理它们的方式完全不同：

• 第一版属于即时拼接型递归：每次递归都会返回${A}${CapitalizeWords<...>}的模板字符串类型，TypeScript需要逐层展开内部的递归调用，每一层都要构建新的字符串类型节点。这种嵌套拼接会让类型实例化的复杂度指数级上升，很快就达到类型系统的递归上限。
• 第二版属于累积参数型递归：遇到非分隔符字符时，只是将字符累积到泛型参数W中，递归时传递的是累积后的字符串，而非即时拼接结果。只有遇到分隔符或字符串结束时，才会调用Capitalize处理累积的单词并完成拼接。这种方式没有嵌套的模板字符串展开，类型系统的负担小得多，能处理更长的字符串。

递归安全上限与触发条件 #

TypeScript并没有公开固定的类型递归深度上限，它取决于类型的复杂度：

• 对于累积参数型递归（如第二版），递归次数等于字符串的字符数，但因为只是传递参数而非构建复杂类型，通常能处理几百甚至上千字符的字符串（具体数值和TypeScript版本、当前环境的类型处理能力有关）。
• 当字符串长度超过类型系统能处理的递归次数，或者累积的参数W过长导致类型实例化负担过重时，才会触发错误。

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