深搜与广搜在 TypeScript 类型递归中的应用

在学习 TypeScript 高级类型时，经常会遇到需要递归处理复杂数据结构的场景。今天在做 FlattenDepth 这道类型挑战时，我发现了一个有趣的现象：同样是实现数组扁平化，不同的递归策略会导致截然不同的性能表现。本文将以这道题为例，深入探讨深度优先搜索（DFS）和广度优先搜索（BFS）在 TypeScript 类型递归中的应用与差异。

问题描述

FlattenDepth 的任务是将嵌套数组按指定深度进行扁平化：

type a = FlattenDepth<[1, 2, [3, 4], [[[5]]]], 2>; // [1, 2, 3, 4, [5]]
type b = FlattenDepth<[1, 2, [3, 4], [[[5]]]]>; // [1, 2, 3, 4, [[5]]] (默认深度为1)

看似简单的需求，但在实现时却有着巧妙的递归策略选择。这道题的核心挑战在于如何高效地控制扁平化的深度，不同的实现思路会产生截然不同的递归行为。

方案一：广度优先搜索（BFS）

实现思路

我最初的实现采用了广度优先的策略：先实现一次扁平化的逻辑，然后递归调用指定次数。这种方法的核心思想是"分而治之"，将复杂的多层扁平化分解为多次单层扁平化。

// 首先实现扁平化一次的逻辑
type FlattenOnce<T extends any[]> = T extends [infer F, ...infer R]
  ? F extends any[]
    ? [...F, ...FlattenOnce<R>]
    : [F, ...FlattenOnce<R>]
  : [];

// 然后递归调用 FlattenOnce
type FlattenDepth<
  T extends any[],
  N extends number = 1,
  A extends any[] = []
> = A['length'] extends N ? T : FlattenDepth<FlattenOnce<T>, N, [...A, '']>;

执行过程详细分析

让我们通过一个具体的例子来深入理解这种广度优先的执行过程。以 FlattenDepth<[1, [2, [3]]], 2> 为例：

第一次递归调用

// 初始状态: T = [1, [2, [3]]], N = 2, A = []
// A['length'] = 0, N = 2，条件不满足，继续递归

// 调用 FlattenOnce<[1, [2, [3]]]>:
// 处理 1: 非数组，直接包含 → [1]
// 处理 [2, [3]]: 是数组，展开 → [2, [3]]
// 结果: [1, 2, [3]]

// 下一次递归: FlattenDepth<[1, 2, [3]], 2, ['']>

第二次递归调用

// 当前状态: T = [1, 2, [3]], N = 2, A = ['']
// A['length'] = 1, N = 2，条件不满足，继续递归

// 调用 FlattenOnce<[1, 2, [3]]>:
// 处理 1: 非数组，直接包含 → [1]
// 处理 2: 非数组，直接包含 → [2]
// 处理 [3]: 是数组，展开 → [3]
// 结果: [1, 2, 3]

// 下一次递归: FlattenDepth<[1, 2, 3], 2, ['', '']>

第三次递归调用

// 当前状态: T = [1, 2, 3], N = 2, A = ['', '']
// A['length'] = 2, N = 2，条件满足，返回 T
// 最终结果: [1, 2, 3]

广搜特征分析

这种方式完美体现了广度优先搜索的特征：

1. 层级处理 ：每次 FlattenOnce 调用都会处理当前数组的所有元素，将所有一级嵌套都展开
2. 统一深度：每次递归都让所有元素的嵌套深度统一减少 1
3. 计数控制 ：通过数组 A 的长度来精确控制递归次数

问题

当我运行测试用例时，发现最后一个测试用例无法通过：

Expect<Equal<FlattenDepth<[1, [2, [3, [4, [5]]]]], 19260817>, [1, 2, 3, 4, 5]>>;

这个方案的致命问题在于递归深度与指定参数直接相关：

1. 线性递归特征 ：无论数组的实际嵌套深度如何，都必须递归调用 FlattenDepth 恰好 N 次

2. 资源消耗：每次递归都需要：

   • 调用 FlattenOnce 遍历整个数组
   • 创建新的累积数组 [...A, '']
   • 维护递归调用栈

3. 递归深度限制：TypeScript 的递归深度限制通常在 100-1000 层之间，19260817 次递归远超这个限制

用数学表达式来说明：

• 时间复杂度：O(N × M)，其中 N 是指定深度，M 是数组长度
• 空间复杂度：O(N)，需要维护 N 层递归栈
• 递归调用次数：恰好 N 次，与实际数据结构无关

所以我们需要转换思路，采用深搜。

方案二：深度优先搜索（DFS）

实现思路

深度优先的策略采用了完全不同的方法：按需递归，在遇到嵌套数组时立即深入处理，而不是等待当前层级处理完毕。这种方法的核心理念是"就地处理"，直接在原始结构上进行深度控制。

type FlattenDepth<
  T,
  S extends number = 1,
  U extends any[] = []
> = U['length'] extends S
  ? T
  : T extends [infer F, ...infer R]
  ? F extends any[]
    ? [...FlattenDepth<F, S, [...U, 1]>, ...FlattenDepth<R, S, U>]
    : [F, ...FlattenDepth<R, S, U>]
  : T;

执行过程详细分析

让我们用同样的例子 FlattenDepth<[1, [2, [3]]], 2> 来理解深度优先的执行过程：

递归树结构分析

FlattenDepth<[1, [2, [3]]], 2, []>  (depth=0)
├─ 处理元素 1 (非数组)
│  → 结果: [1]
└─ 处理元素 [2, [3]] (数组)
   ├─ FlattenDepth<[2, [3]], 2, [1]>  (depth=1)
   │  ├─ 处理元素 2 (非数组)
   │  │  → 结果: [2]
   │  └─ 处理元素 [3] (数组)
   │     └─ FlattenDepth<[3], 2, [1, 1]>  (depth=2)
   │        └─ depth=2，达到限制，返回 [3]
   │        → 结果: [3]
   │  → 合并结果: [2, 3]
   └─ 最终合并: [1, 2, 3]

分步执行过程

第一层递归：

// T = [1, [2, [3]]], S = 2, U = []
// U.length = 0 < 2，继续处理

// 解构: F = 1, R = [[2, [3]]]
// F 不是数组，所以: [1, ...FlattenDepth<[[2, [3]]], 2, []>]

第二层递归：

// T = [[2, [3]]], S = 2, U = []
// 解构: F = [2, [3]], R = []
// F 是数组，所以: [...FlattenDepth<[2, [3]], 2, [1]>, ...FlattenDepth<[], 2, []>]
//              = [...FlattenDepth<[2, [3]], 2, [1]>, ...]

第三层递归：

// T = [2, [3]], S = 2, U = [1]
// U.length = 1 < 2，继续处理
// 解构: F = 2, R = [[3]]
// F 不是数组，所以: [2, ...FlattenDepth<[[3]], 2, [1]>]

第四层递归：

// T = [[3]], S = 2, U = [1]
// 解构: F = [3], R = []
// F 是数组，所以: [...FlattenDepth<[3], 2, [1, 1]>, ...]

第五层递归：

// T = [3], S = 2, U = [1, 1]
// U.length = 2 = S，达到深度限制
// 直接返回 T = [3]

深搜特征分析

这种方式体现了深度优先搜索的核心特征：

1. 就地决策：遇到数组立即决定是否深入，不需要等待同级元素处理完毕
2. 路径记录 ：用 U 数组记录当前的递归路径深度
3. 早期剪枝：一旦达到指定深度就停止深入，直接返回原结构
4. 分治合并：将问题分解为"处理当前元素"和"处理剩余元素"两个子问题

优势分析

这种方式的关键优势在于：

1. 自适应递归深度

// 对于 `FlattenDepth<[1, [2]], 1000>`
// 实际只需要2层递归，而不是1000层

2. 早期终止机制

// 一旦某个分支达到指定深度，立即停止该分支的处理
// 避免不必要的递归调用

3. 空间效率优化

// 不需要创建完整的中间结果数组
// 只需要维护当前递归路径的深度信息

对于测试用例 FlattenDepth<[1, [2, [3, [4, [5]]]]], 19260817>：

• 实际嵌套深度 ：只有 4 层 [[[[[5]]]]]
• 递归行为：在第 4 层就会完成所有必要的扁平化
• 关键洞察：指定深度 19260817 虽然很大，但实际递归深度由数据结构决定
• 性能优势：总递归调用次数约为 O(数组长度 × 实际深度)，而非 O(指定深度)

深搜与广搜的本质差异

在算法中的表现

特性	广度优先搜索 (BFS)	深度优先搜索 (DFS)
空间复杂度	O(w) - 最大宽度	O(h) - 最大深度
时间复杂度	O(V + E)	O(V + E)
内存使用	需要存储整层节点	只需存储路径上节点
最优解	保证最短路径	不保证最优

在类型递归中的表现

广搜策略 (逐层处理) ：

• ✅ 逻辑清晰，易于理解
• ❌ 递归深度与指定参数成正比
• ❌ 容易触发递归限制
• ❌ 需要处理大量中间状态

深搜策略 (按需深入) ：

• ✅ 递归深度与实际嵌套深度相关
• ✅ 更少的递归调用
• ✅ 更好的性能表现
• ❌ 逻辑相对复杂

性能对比实验

让我们用具体的例子来验证两种方案的差异：

// 测试用例1: 浅层嵌套，大深度参数
type Test1_BFS = FlattenDepth<[1, [2]], 1000>; // BFS: 需要1000次递归
type Test1_DFS = FlattenDepth<[1, [2]], 1000>; // DFS: 只需要2次递归

// 测试用例2: 深层嵌套，小深度参数
type Test2_BFS = FlattenDepth<[[[[[1]]]]], 2>; // BFS: 需要2次递归
type Test2_DFS = FlattenDepth<[[[[[1]]]]], 2>; // DFS: 需要约10次递归

// 测试用例3: 复杂结构
type Test3 = FlattenDepth<[1, [2, [3, [4]]]], 10>;
// BFS: 10次递归，每次处理整个数组
// DFS: 按树结构递归，总次数取决于实际结构

实际应用指导

何时选择广搜策略

// 场景1: 需要逐层处理，且层数可控
type ProcessByLevel<T> = T extends SomeCondition
  ? ProcessCurrentLevel<T>
  : ProcessByLevel<NextLevel<T>>;

// 场景2: 需要保证处理顺序
type BreadthFirstTraversal<T> = // 逐层遍历实现

何时选择深搜策略

// 场景1: 处理树状结构，深度不可预测
type DeepTreeOperation<T> = T extends [infer Head, ...infer Tail]
  ? Head extends SomeType[]
    ? [...DeepTreeOperation<Head>, ...DeepTreeOperation<Tail>]
    : [ProcessHead<Head>, ...DeepTreeOperation<Tail>]
  : T;

// 场景2: 需要优化递归深度
type OptimizedRecursion<T, Depth extends number = 0> = Depth extends MaxDepth
  ? T // 早期终止
  : T extends ProcessableType
  ? OptimizedRecursion<Process<T>, Add<Depth, 1>>
  : T;

总结与思考

通过 FlattenDepth 这道题，我们可以看到：

1. 算法思维在类型编程中同样重要：传统算法中的搜索策略完全适用于 TypeScript 类型递归

2. 性能考虑不可忽视：TypeScript 的递归深度限制要求我们必须谨慎选择递归策略

3. 问题特性决定最优方案：

   • 如果递归深度与输入参数强相关 → 考虑深搜
   • 如果需要逐层处理且层数可控 → 可以考虑广搜
   • 如果面临递归深度限制 → 优先考虑深搜

4. 可读性与性能的权衡：有时候更复杂的实现能带来显著的性能提升

在实际的 TypeScript 类型编程中，我们应该：

• 分析问题的本质特征
• 预估递归深度
• 选择合适的搜索策略
• 在必要时进行性能优化

希望这篇文章能帮助大家在遇到类似问题时，能够更好地选择和实现递归策略。TypeScript 的类型系统虽然强大，但也需要我们运用正确的算法思维来驾驭它。