泛型嵌套过深触发编译器递归深度限制，表现为“Excessive stack depth”等错误；需通过错误信息定位嵌套源头、检查递归终止条件、优化类型定义并启用诊断工具排查。
泛型嵌套过深导致类型推断失败，本质是编译器在类型检查阶段触发了递归深度限制或陷入无限展开。这不是代码逻辑错误，而是类型系统的能力边界问题。排查需从错误现象出发，逐层定位嵌套源头和触发点。
观察编译错误信息定位关键线索
TypeScript 报错如 “Excessive stack depth comparing types” 或 “Type instantiation is excessively deep and possibly infinite”，说明类型比较/实例化已超出默认深度（TS 默认为 100 层）。这类错误通常伴随具体类型名，比如 Maybe<maybe>>></maybe> 或 DeepPartial<deeppartial>></deeppartial>。重点关注错误消息中反复出现的类型名和嵌套结构，它们就是嵌套源头。
- 运行
tsc --noemit获取纯净类型错误，避免输出干扰 - 若使用 VS Code，将鼠标悬停在报错位置，查看“Quick Info”中展开的完整类型，确认是否出现明显重复嵌套
- 搜索项目中该类型名的定义与所有使用处，尤其是高阶工具类型、递归映射、或 codegen 自动生成的类型
检查递归类型定义是否缺少终止条件
合法的递归类型必须有明确的“退出分支”，否则编译器无法判定何时停止展开。常见陷阱是条件类型或映射类型中未覆盖基础类型（如 string、number、null）或未用 never 截断。
- 检查类似
type DeepReadonly<t> = T extends object ? { readonly [K in keyof T]: DeepReadonly<t> } : T;</t></t>的定义——它对object递归，但function、array、date等也满足object，易造成意外循环 - 改用更精确的约束，例如
T extends Record<string unknown></string>，并显式处理Array、Function等内置类型 - 在递归调用前加入浅层守卫，如
['__is_deep__', 'depth'] in T ? never : ...，人为设限
审查泛型工具链中的隐式嵌套调用
类型推断失败常不发生在定义处，而是在组合使用时爆发。多个泛型类型相互传递，每一层都引入一次泛型参数展开，快速堆叠深度。
- 检查是否连续使用了多个高阶类型，例如
Partial<omit k>>, L>></omit>—— 每个工具类型都可能递归处理内部属性 - 避免在泛型函数返回类型中直接嵌套另一泛型类型，如
function wrap<t>(x: T): Promise<observable>></observable></t>；改用中间类型别名提前收口 - 对高频使用的嵌套类型，提取为具名类型并加注释说明最大嵌套层级，例如
type SafeDeepPartial<t> = DeepPartial<t> & { __maxDepth: 5 };</t></t>
启用调试与临时降级验证
当常规手段难以定位时，可借助编译器调试能力缩小范围。
- 在
tsconfig.json中添加"extendedDiagnostics": true，运行tsc --noemit查看详细耗时与类型展开路径 - 临时注释掉疑似复杂的类型定义或导入，观察错误是否消失；再逐行恢复，锁定最小复现单元
- 尝试设置
"maxNodeModuleJsDepth": 0排除 node_modules 中第三方类型影响（尤其含复杂泛型的库如zod、io-ts）
