AngstEssenSeele递归函数这个东西，我敢说每个写代码的人都见过，但真正能把它用明白、设计利索的，其实不多。很多人是“看得懂，写不出”，一遇到递归就头皮发麻；还有人倒是敢写，结果一跑就爆栈，或者死循环到天荒地老。我刚入行那会儿，接过一个老项目，里面有个组织架构树要算每个节点下面挂了多少人。同事用嵌套 for 循环写了几层，逻辑绕得跟毛线球一样，后来我顺手用递归重写了一遍，十几行搞定，测试一次通过。从那以后我就意识到，递归这个东西，懂原理只是第一步，会用、敢用、能设计好，才是真正拉开差距的地方。
这篇我就打算把递归函数的使用和设计掰开了讲。不整虚的，从调用栈到底层原理，从经典写法到实战场景，再把我这些年踩过的坑、总结的调试招数统统倒出来。无论你是刚学会写函数的初学者，还是写了几年业务代码但一直没搞懂递归的老开发，这篇应该都能让你有点收获。
1. 先想明白递归到底是什么：它不是魔法，是栈的规矩
很多人觉得递归难，是因为把它当成了一种“函数调用自身的魔法”。其实递归的底层机制一点都不神秘，它依赖的是程序运行时的调用栈。
1.1 每次调用都在“搭栈帧”，你可以把它想成叠盘子
编程语言在调用一个函数的时候，会往内存里一个叫“调用栈”的区域压入一条记录，这条记录叫栈帧。栈帧里保存的信息大致包括：当前函数的参数值、局部变量、返回值要交给谁、调用完成后下一行指令的地址。等到函数执行完毕，这个栈帧就会从栈顶弹出，控制权回到之前的位置。
递归的本质就是“没有执行完的函数暂时不退出，又去调用了一个自己的副本”。比如你写了一个求 n 的阶乘的函数：
python复制def factorial(n):
if n == 1:
return 1
return n * factorial(n - 1)
当你调用 factorial(4) 的时候，运行时先把 factorial(4) 的栈帧压进去，发现它要算 4 * factorial(3)，于是 factorial(3) 的栈帧又压进去，接着 factorial(2)、factorial(1) 依次入栈。当 factorial(1) 命中了终止条件，直接返回 1，这时候栈才开始一个个往外弹：factorial(2) 算出 2，factorial(3) 算出 6，factorial(4) 算出 24。
这里一个最关键的心法就是：递归不是同时调用了多个函数，而是同一个函数的不同帧在栈里排队等待。 你把它想成食堂阿姨叠盘子，一个盘子没洗完就放到一边，先去洗下一个盘子，等洗到最后一个盘子才回头一个个把之前的盘子补完。这个过程非常符合人的直觉。
1.2 终止条件为什么叫“递归的命根子”
递归函数如果没有终止条件，就会无限地压栈。栈内存总归是有限的，压到一定程度系统就会强制中断，报出类似于 RecursionError: maximum recursion depth exceeded 或者 StackOverflowError 的错误。所以设计递归的第一条军规：先确保存在终止条件，并且每递归一层，问题规模必须向终止条件逼近。
有人会说，我明明写了 if n == 1: return 1 啊，为什么还是死循环？这种情况下，多半是递归调用时参数的变化没有“收敛”。比如：
python复制def bad_recursion(n):
if n == 1:
return 1
return bad_recursion(n - 1) + bad_recursion(n - 2)
如果初始 n 是 2，那它会无限递归下去，因为 bad_recursion(2) 会调用 bad_recursion(1) 和 bad_recursion(0)，而 0 不满足终止条件 n == 1，于是又调 bad_recursion(-1)、bad_recursion(-2)……永远没完没了。这里的问题就是：递归步没有把问题严格推进到终止条件上——n 减过头了，跳过了终止条件的检测范围。
1.3 递归与循环的本质区别：谁在存中间状态
为什么同样的逻辑循环也能写？比如我上面提到的组织架构树统计人数，用循环写也可以，但往往需要自己维护一个栈或队列来记录“接下来还有哪些节点要处理”。递归的最大优势其实在于：中间状态由调用栈自动帮你保存了，你不用自己设计数据结构去存“刚才算到哪了”。
举个例子，遍历二叉树，如果用递归，极简：
python复制def inorder(node):
if node is None:
return
inorder(node.left)
print(node.val)
inorder(node.right)
如果不用递归，你需要手动维护一个栈，模拟遍历过程中不断变化的指针状态。虽然性能上不一定差多少，但代码可读性和维护性差距是非常明显的。递归是把你脑子里的“先处理左边、处理完回来处理根、再去处理右边”直接翻译成代码；循环是在让你手动管理一个微型状态机。哪个好写，哪个好读，一眼便知。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 设计递归函数的核心套路：三步法和两个关键问题
递归难在“怎么设计”。我自己的习惯是拿到一个问题先不急着写代码，而是先问自己三个问题：子问题是什么？递归关系是什么？终止条件是什么？这套方法，我称之为“递归设计三步法”。
2.1 第一步：找出可拆解的“子问题”
递归之所以可行，是因为很多复杂问题天然具备“自相似性”。比如你要算一棵树的高度，树的高度 = 左子树高度和右子树高度中的较大值 + 1。这里的子问题就是“计算某棵子树的高度”，跟原问题一模一样，只是规模变小了。
找子问题的时候，有一个非常实用的小技巧：假设你已经把规模更小的问题解决了，不要去关心它是怎么解决的。 比如设计斐波那契函数时，直接假设 fib(n-1) 和 fib(n-2) 已经给你算好了，你只需要决定怎么把它们组合起来。这就是“递归的信念一跃”。很多新手写递归时总想着把每一步展开，头脑里模拟整个递归栈，结果把自己绕晕。我在带人写代码时经常说：不要试图用你的脑子去跑递归，计算机比你擅长这个，你只负责定义规则。
2.2 第二步：写清楚递归公式与终止条件
继续拿走迷宫举例。迷宫问题在计算机里常常被抽象成二维网格上的路径搜索，递归版本的设计思路是这样的：
- 终止条件：当前位置就是出口，或者已经走到了死路（越界/撞墙/已访问）。
- 递归关系：下一步可以向上、下、左、右走，只要某个方向能走通，当前路径就是通的。
代码大概长这样：
python复制def can_exit(maze, x, y, visited):
if x < 0 or x >= len(maze) or y < 0 or y >= len(maze[0]):
return False
if maze[x][y] == '#':
return False
if (x, y) in visited:
return False
if maze[x][y] == 'E':
return True
visited.add((x, y))
if can_exit(maze, x + 1, y, visited):
return True
if can_exit(maze, x - 1, y, visited):
return True
if can_exit(maze, x, y + 1, visited):
return True
if can_exit(maze, x, y - 1, visited):
return True
return False
注意这里的 visited 解决了两个问题：一是防止无限兜圈，二是避免重复计算。这个设计相当典型，每个递归分支都共享同一个 visited 集合，它的作用相当于全局状态。
2.3 第三步：相信递归，但要用输入输出验证
函数写完之后不要急着跑大数据，先用手算小规模测试用例。比如阶乘，测试 factorial(1)、factorial(2)、factorial(3)；二叉树的遍历测试只有三五个节点的树；走迷宫就画一个 3x3 的小地图。小用例能快速验证终止条件是否合理，递归关系是否错误，定位起来也方便。
这里我想额外强调一个经验：写递归函数的时候，尽量把递归关系写得“线性清晰”，不要把多个递归调用隐藏在一个复杂表达式里。 例如：
python复制def f(n):
return f(n - 1) + f(n - 2) * f(n - 3) - f(n - 4)
这种虽然也能算，但一旦结果不对，排查起来非常痛苦。宁可拆成多行，每步都赋给有名字的变量，或者至少让逻辑结构一目了然。递归本身就不容易调试了，就别再给自己挖额外的坑了。
3. 经典场景挨个过：从树形结构到回溯思想的实战
理论聊完就得来点实际的。递归真正发光发热的场景有哪些？我挑三个最常见的类型展开讲讲，都附上可以立刻抄走的代码。
3.1 树形结构遍历：最标准的递归练习
树是最适合练递归的数据结构，没有之一，因为它天然就是递归定义的：一棵树由根节点和若干子树构成，子树本身也是一棵树。所以几乎所有树操作都可以无脑递归。
比如统计二叉树的节点个数：
python复制def count_nodes(root):
if root is None:
return 0
return 1 + count_nodes(root.left) + count_nodes(root.right)
我把这三行代码给很多新人看过，他们第一反应是：“就这？这就数完了？”没错，递归的美妙之处就在这里。你不是在描述数节点的过程，而是在描述节点数的定义：当前节点算一个，加上左子树所有节点，再加上右子树所有节点。定义即实现，这就是递归的表达力。
再比如判断一棵二叉树是不是对称的：
python复制def is_symmetric(root):
return check(root, root)
def check(left, right):
if left is None and right is None:
return True
if left is None or right is None:
return False
return left.val == right.val and check(left.left, right.right) and check(left.right, right.left)
这个递归设计的关键点是：对称树的“左子树要和右子树互相对称”，所以递归里传入的不是同一棵树的两半，而是“理应相互镜像”的两个节点。这类递归的难度在于参数设计——递归函数该接收哪些参数，是在纸上就要想清楚的。
3.2 二叉树路径相关的递归模式
除了最简单的遍历和计数，树形递归更常见的场景是计算路径、深度等等。比如求二叉树所有从根到叶子节点路径中，数值之和等于 target 的路径条数，或者直接列出所有路径。这类问题的共同套路是：递归函数里带着“当前路径”或“当前累积值”。
python复制def has_path_sum(root, target):
if root is None:
return False
remaining = target - root.val
if root.left is None and root.right is None:
return remaining == 0
return has_path_sum(root.left, remaining) or has_path_sum(root.right, remaining)
这种“把目标值通过参数层层传递，每走一层就减掉当前节点值”的方式，比在每个递归里反复求“路径和”要高效得多，也自然得多。核心思想是：不用等走到叶子再去算整条路径的和，而是一边往下走，一边把要满足的条件缩小。
这个模式我特别建议编程新手背诵理解。它是“递归传参”的经典示范：递归函数不仅要传“我在哪”，还要传“我还需要满足什么条件”。
3.3 回溯法：递归的集大成者
回溯算法本质上是“对递归分支进行穷举，并在失败时撤销选择”。它适用于组合、排列、子集、数独解算、八皇后等一大批问题。回溯函数模板我个人觉得比树遍历更值得吃透，因为可以在很多非树问题里复用。
以“生成 n 对括号的所有有效排列”为例：
python复制def generate_parentheses(n):
result = []
def backtrack(current, opened, closed):
if len(current) == 2 * n:
result.append(current)
return
if opened < n:
backtrack(current + '(', opened + 1, closed)
if closed < opened:
backtrack(current + ')', opened, closed + 1)
backtrack('', 0, 0)
return result
这里有三个动作很典型：尝试一种可能的选项、递归进入下一层、不用显式“撤销”是因为每次传入的都是当前字符串加新字符的副本，所以当前层状态没有被污染。如果用的是列表或者字典这类可变对象，就得在递归完成后显式撤销，这也是回溯最容易出 bug 的地方。比如经典的全排列写法：
python复制def permute(nums):
result = []
def backtrack(path, used):
if len(path) == len(nums):
result.append(path[:])
return
for i in range(len(nums)):
if used[i]:
continue
used[i] = True
path.append(nums[i])
backtrack(path, used)
path.pop()
used[i] = False
backtrack([], [False] * len(nums))
return result
这一步 path.append 之后递归，递归完再 path.pop，这种“先选，再递归，后撤销”的顺序，是回溯法的固定节奏。很多新手漏了 pop 或者漏了把 used 恢复 false，结果就会得到一堆奇怪结果。
我在刷题群带新手通过这段代码时，最爱强调的就是：回溯递归中“撤销”是人为的，因为你在递归里借用的是同一个可变对象；如果你每次传入一个拷贝，那确实不用撤销，但拷贝开销大，路径一长就撑不住了。 理解这一层，逻辑才能真的立住。
4. 性能与隐患：递归不是免费的午餐
递归写起来爽，但跑起来不一定爽。这里面最核心的隐患有三个：重复计算失控、调用栈深度爆掉、以及隐藏在背后的函数调用开销。
4.1 斐波那契的反面教材：重复计算的雪崩效应
课本上最经典的递归例子是斐波那契：
python复制def fib(n):
if n <= 1:
return n
return fib(n - 1) + fib(n - 2)
这段代码看起来简洁，实际性能非常糟糕。fib(40) 基本就要等好几秒了。原因在于它存在海量重复计算。画一下它的递归树你就会发现：fib(5) 要算 fib(4) 和 fib(3)，fib(4) 又要算 fib(3) 和 fib(2)……下面的子问题被反复算了无数遍。这个耗时是按指数爆炸式增长的，n 稍微大一点，宇宙毁灭了都算不完。
解决重复计算的标准方案是记忆化，也叫备忘录递归：
python复制def fib(n, memo=None):
if memo is None:
memo = {}
if n in memo:
return memo[n]
if n <= 1:
return n
memo[n] = fib(n - 1, memo) + fib(n - 2, memo)
return memo[n]
从设计角度来说，这里就是给“递归状态”加了一层缓存。每次算出某子问题的结果，就存进字典；下次再遇到同样的子问题，直接取缓存。加了这一层之后，fib(100) 都能秒出结果。
经验之谈：如果发现某个递归跑得特别慢，第一反应就去画递归树，判断里面有没有大量相同的子问题。有，就用记忆化。不是所有递归都需要记忆化，但如果每个分支都在解决同一个小子问题，那缓存就是必须品。
4.2 栈溢出与 Python 的递归上限
每个语言对递归深度都有自己的天花板。Python 默认递归深度差不多 1000 层多一点，超过之后直接抛 RecursionError。Java 的默认栈大小一般在 512KB 到 1MB 之间，深了之后抛 StackOverflowError。C++ 也类似，取决于栈空间配置。
举个例子，你写了一个递归深度为 n 的函数，然后在循环里调用它，n 稍微大点，比如 100000，Python 里会炸；Java 也一样炸。这时候记不记忆化都没有意义，因为问题不是“算得慢”，而是“根本没能力深入这么多层”。
针对这种情况，有几种应对思路：
- 调整递归深度限制（Python 里可以用 sys.setrecursionlimit(1000000)）。这个办法能用，但本质上是在赌栈空间够大，治标不治本。
- 改成迭代写法，用自己维护的栈来模拟递归。例如把二叉树遍历改成显式栈，深度限制就变成了内存限制，可用空间大了很多。
- 改用尾递归优化。可惜 Python、Java 主流实现都不做尾递归优化，所以这条路在大多数业务代码里走不通。
4.3 尾递归到底是怎么回事
尾递归指的是递归调用是函数体中最后一个操作，并且这个递归调用的返回值会直接被当前函数返回。例如：
python复制def tail_factorial(n, acc=1):
if n == 0:
return acc
return tail_factorial(n - 1, acc * n)
理论上编译器如果支持尾调用优化，这个递归可以复用同一个栈帧，不增加栈深度。但因为 Python 不优化尾递归，Java 也不强制优化，所以你在这些语言里写尾递归意义不大。很多工程师会告诉你“用尾递归避免栈溢出”，在 Python 里这句话是无效的。要不要用尾递归，先看语言支不支持，别盲目听网上的方案。
4.4 递归栈深度太深的场景该怎么办
我自己的经验是这样：如果递归深度很浅，比如树的深度也就是几十层，那随便递归，写起来又爽又清晰。如果递归深度可能上万层，就先停下来掂量一下——能用分治思路把递归深度控制在 log n 吗？如果不行，大概率要考虑显式栈来模拟。
拿树的遍历来说，用显式栈写中序遍历并没有那么可怕：
python复制def inorder_iterative(root):
result = []
stack = []
cur = root
while cur is not None or stack:
while cur is not None:
stack.append(cur)
cur = cur.left
cur = stack.pop()
result.append(cur.val)
cur = cur.right
return result
这个写法跟递归版的差别就是：你自己把递归中由调用栈保存的“待处理节点”放进了显式栈。当然代码确实更绕，但对非常深的树是保命方案。
5. 递归的进阶设计：从“入门”到“会用”要掌握的几种形态
递归不只有单路递归和双路递归。在真实工程和算法题里，会出现各种有微妙差异的递归形态。掌握它们，帮你在看到一道题的时候快速判断能用什么递归策略。
5.1 线性递归与树形递归
线性递归的特征是递归调用只会出现一次，例如阶乘：每层递归只调用一次自身，展开后是一条线。树形递归的特征是每层会调用多次自身，比如斐波那契和二叉树遍历，展开后是一棵树。区分这两者对复杂度估算非常关键。
树形递归如果不带记忆化，时间复杂度往往是指数级别，因为每个节点还可能继续分裂出多个子节点。而线性递归的时间复杂度通常跟递归深度或者单层操作复杂度直接相乘即可。
5.2 直接递归 与 间接递归
直接递归是函数 A 直接调用 A，容易识别。间接递归是 A 调 B，B 又调 A，或者 B 调 C、C 调 A，这样绕了一圈回到自己。间接递归在分布式系统、状态机设计中偶尔会出现，但调试起来不太直观。如果真在项目里碰到了，我通常建议画一张“函数调用关系图”，确认循环确实能收敛，而不是在几个函数之间打转。
一个很隐蔽的间接递归 bug 出现在业务代码里：业务 B 调用服务 A，服务 A 通过回调又调用业务 B，最后形成死循环。这种在监控系统里表现为“调用链路漂移”，不是单纯看代码就能一眼定位的。
5.3 分治递归：一分为二，各自解决
分治思想是递归的另一个高峰。典型场景是归并排序、快速排序、二分查找。拿归并排序来说，把数组对半劈开，递归把左半边排序，递归把右半边排序，最后合并两个有序数组。
python复制def merge_sort(arr):
if len(arr) <= 1:
return arr
mid = len(arr) // 2
left = merge_sort(arr[:mid])
right = merge_sort(arr[mid:])
return merge(left, right)
分治递归相比于暴力树形递归，它的递归深度是 log n，因为每层规模减半。这种“对数深度”特性让它在工程上非常安全，处理百万数据也没问题。所以遇到一个问题时，我会先想：能不能把大规模问题拆成相互独立的若干份？如果能，大概率分治递归是最优雅的解。
5.4 自底向上与自顶向下：递归的一体两面
设计递归的时候，可以从两个方向思考。自顶向下是把大问题拆成小问题，依赖小问题的结果返回；自底向上是先解决最基础的子问题，再逐层向上推导。比如动态规划题目里面，记忆化递归是自顶向下，for 循环填表是自底向上，它们遵循的是同一个递推公式。
我个人的习惯是：如果递推关系很容易抽象，就写记忆化递归，代码跟数学公式几乎一一对应；如果递推需要依赖前面的多个状态且状态表复杂度高，就写迭代填表，性能和可控性更好。 两种方法没有绝对优劣，能解决当前问题、别人能看懂的，就是好办法。
6. 实战坑位自查：递归调试的独门经验
递归写多了，谁还没踩过几个坑。我把这些年遇到过的典型问题梳理成一套排查方法和避坑笔记。
6.1 常见报错速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| RecursionError / StackOverflowError | 缺少终止条件，或递归层数超过默认限制 | 检查 base case 是否可达；打印递归参数观察是否收敛 |
| 结果是 None | 递归分支里漏写了 return | 检查每个分支是否有明确的返回值，尤其注意 if 分支中的 return 是否写全 |
| 结果正确但异常慢 | 重复计算大量子问题 | 画递归树，引入 memoization 缓存 |
| 结果错乱、像是“被污染” | 可变对象在递归中共享，未正确复制或回溯时未撤销 | 检查参数用的是列表还是元组对象，必要时深拷贝 |
| 死循环 / 卡死 | 递归参数没有单调变化，或者访问了已访问过的状态 | 给每个状态做 visited / visited 标记，显式增加访问记录 |
这个表做出来之后，我经常分享给团队新人，让他们报错的时候先对着表自查一遍，省得浪费大量时间在毫无头绪的试错上。
6.2 递归调试神技：加打印看“缩进轨迹”
递归最麻烦的地方在于没法单步跟，因为你人脑跑一个树形递归非常吃力。我常用的调试方案是打印带缩进的调用轨迹。例如：
python复制def debug_factorial(n, depth=0):
print(' ' * depth + f'call factorial({n})')
if n <= 1:
print(' ' * depth + f'return 1')
return 1
result = n * debug_factorial(n - 1, depth + 1)
print(' ' * depth + f'return {result}')
return result
运行之后，控制台会清晰地展示出“先一路下钻到最底层，再一层层回溯返回”的完整路径。这个方法能帮你确认每一层的返回值是否符合预期。一旦结果错乱，从最后一层往回检查，非常容易定位。
6.3 警惕全局可变状态的共享污染
写递归时将可变结构作为全局变量或者类属性使用，是一个高频坑。比如在类里面定义一个 self.result = []，然后递归里直接 self.result.append(...)，又忘记在回溯时清理。如果存在多条递归路径，上一次路径残留的数据可能会污染当前结果。
规避方案：递归里尽量只通过参数传递状态，返回时用返回值组合；如果必须共享一个全局容器，例如收集所有路径，把“添加结果”这个动作尽量控制在递归树的叶子节点或者完全独立的分支里执行。 同时一定注意是否要 copy 一份再添加，防止后续回溯操作把已经保存的结果改坏了。
6.4 记忆化递归里的缓存键设计要思考清楚
记忆化虽然好用，但缓存键不能随便拍脑袋。理论上缓存键要完整表达“这个子问题的输入特征”。比如处理二维网格路径时，递归参数是 (x, y)，缓存键就是 (x, y)。但如果递归参数里包含当前路径的集合，缓存就没有多大意义了，因为路径集合不同，子问题虽然坐标相同，但未来可选的方向已经不同。这种情况下强行记忆化甚至可能产生错误答案。
我见过不少人把记忆化用错，就是因为他们没想明白“什么算重复的子问题”。设计记忆化时，可以问自己：如果两个递归调用参数一模一样，它们的未来计算结果是否一定相同？如果存入了路径相关状态，答案就是否定，就不能只拿坐标做缓存键。
6.5 实际处理超深递归时，怎么确定能承载的极限深度
这个数值因语言、平台、栈配置和单层局部变量大小而异。单层栈帧占用越小，能递归的层数就越多。比如一个只接收一个整数参数的函数，跟一个接收一个大数组、好几个大字典的函数，单层帧的占用完全不是一个量级。实际项目中想大致探个底，可以写一个纯递归空函数，不断递增参数 depth，直到捕获到栈溢出异常为止。
但我要特意提醒一句：栈溢出本身是个严重错误，靠 try-catch 去捕获后“扭转乾坤”并不是工程正道。 它更像是一次性的探测手段，帮你在上线前确认当前环境的栈上限，从而决定应该采用递归还是迭代方案。
7. 怎么在真实项目里优雅地选型
看完全部原理和案例，很多人会问：所以以后我到底是无脑递归，还是无脑迭代？我的答案是：看场景，没有银弹。
7.1 适合递归的场景
- 数据本身有递归定义，比如树、图、嵌套列表。
- 需要回溯穷举，比如排列组合、REST 风格路由的嵌套匹配。
- 问题能干净地拆成同构子问题，比如归并排序、二分查找。
- 团队其他成员对递归掌握到位，代码的可读性高于对性能的极致追求。
7.2 适合迭代/显式栈的场景
- 递归深度不可控，可能达到数万甚至百万层。
- 对时间和内存极度敏感，函数调用开销都不容忽视。
- 语言运行时没有对递归做额外优化，比如 Python 或默认配置下的 JVM。
- 需要并发处理或在极小的嵌入式环境里跑，栈内存极其有限。
7.3 我的工程心法：安全递归的自我检查清单
列几个上生产前我会反复确认的问题：
- 是否有明确的终止条件？最坏情况下参数是否一定收敛到这里？
- 单层递归是否维护了正确的不变量？比如回溯撤销是否配对？
- 递归深度是否在目标环境的安全范围以内？
- 是否可能存在重复计算？如果有，是否做了记忆化？
- 全局可变状态是否做了隔离？保存结果时是否拷贝了快照？
- 如果某个分支抛异常，栈帧上的资源是否能正常释放？
8. 几个能帮你开窍的训练题与验证思路
理论讲了这么多，真正内化还是得靠练。我推荐一套循序渐进的自测路径，每个都可以用递归设计，同时对比迭代实现。
- 反转字符串、判断回文字符串。
- 求数组的最大值、平均值，要求不用循环只用递归。
- 二维网格中岛屿数量统计（这也是递归深度搜索或回溯的典型）。
- 排列组合、子集生成、括号生成。
- 给定一个数组和一个目标值，选若干数字使和等于目标，输出组合。
- 求二叉树的最大深度、最小深度、判断平衡二叉树。
练的时候有一个标准动作：先写递归，再分析它的时间复杂度，再画递归树，再把递归改为迭代，再比较差异。一轮下来，不仅能掌握递归，对数据结构、状态管理、复杂度分析都会有明显提升。
我自己每次带新人过这套训练，都要求他们写完后“亲手模拟一次递归展开”：准备一张纸，写出 n=4 时函数每一步的入栈和出栈过程。这个动作看似笨拙，但对建立递归心智模型极其有效，比看十篇文章都有用。
9. 最后分享一点我个人的体会
递归函数这东西，很容易被两种极端态度对待：一种是把递归奉为神技，什么题都递归，不管性能；另一种是避递归如虎，业务代码里见到递归就想干掉改成循环。我在实际工程中体会最深的一句话是：递归不是为了炫技，而是为了让人觉得代码就是“定义本身”，读起来不用翻译。 如果一个递归实现能让读者三秒钟看懂逻辑，它就是好设计；如果还得画半天图才能理解，那可能就是一个失败的抽象，不如用循环。
另外提醒一句，团队协作时，递归的合法性往往不取决于你的代码能力，而取决于团队里其他人的维护能力。只要项目不是只有你一个人看的，就尽量在递归入口留好注释，写清楚递推关系和终止条件，免得后来接手的人对着几十行递归干瞪眼。这些看似不起眼的功夫，才真正决定一个方案在项目里能不能长久活下来。