先说说我遇到的一次事故。线上有个解析多级评论的接口数据嵌套深度到了一定规模之后突然开始报RecursionError: maximum recursion depth exceeded。当时第一反应很朴素调大sys.setrecursionlimit呗。结果改完上线没几分钟进程直接段错误退出——不是普通异常是整个 Python 进程当场没了。那次之后我才真正把“递归极限”和“缓存策略”这两件事分开想明白一个是调用栈空间的问题一个是重复计算浪费性能的问题。很多人被这两个问题同时卡住不是技巧不够而是没意识到它们根本不在一层。这篇就把递归为什么会爆栈、lru_cache怎么设计才合理、遇到深树和重叠子问题该怎么重构一次讲透。1. 先搞懂递归的“上限”从哪来影响 Python 调用深度的是栈不是代码1.1 RecursionError 不是“代码跑久了”的报错而是调用栈满了Python 里每次函数调用解释器都会往调用栈上压一个帧对象这个帧记录了函数的局部变量、参数、返回地址等运行信息。函数return之后这个帧才被弹出。递归不过是把这个过程重复了很多次每一层递归都要等下一层返回所以每一层的帧都不能提前释放只能一层层叠在栈里。RecursionError的触发点其实很直白。CPython 解释器内部有一个递归计数器每次进入函数体就加一每次返回就减一一旦发现当前递归深度接近上限就直接抛异常。这段代码是经典的演示def f(): return f() f()运行之后你会看到密密麻麻的 traceback最后一行就是RecursionError。注意它不是在“代码逻辑跑错了”之后出现而是在“函数调函数调函数把栈叠满”的那一刻出现。所以排查这种错误第一件事就是搞清楚你的代码是不是真的需要这么深的递归还是纯粹基线条件没写对导致无限递归。我见过不少初学者一看到RecursionError就想着调大递归上限结果发现错误还在。原因很简单如果递归写错了调大上限只是延长崩溃前的等待时间并没有解决逻辑问题。比如有人写树遍历忘记处理叶子节点返回于是递归永远不会真正结束。1.2 默认递归上限为什么是 1000动了它发生了什么先用工具看一下默认值import sys print(sys.getrecursionlimit()) # 1000这个 1000 不是随便拍脑袋定的它本质上是 CPython 为了“保护程序不在 C 栈溢出时直接炸掉进程”而设置的一个偏保守的阈值。Python 解释器执行函数调用时表面上是在执行字节码但函数调用本身会经由 C 层面完成而 C 函数调用同样会消耗系统分配的真实栈空间。每一层 Python 递归都叠在系统栈上叠太多了就会越过操作系统给线程分配的栈边界轻则抛出异常重则直接段错误。有个很形象的说法真实调用栈就像你往桌上叠盘子。Python 层控制的是“最多叠 1000 个就把手缩回去”但如果你强行把手抬高说“我能叠一万个”操作系统并不买账——万一你手一抖把整个桌子压塌了那就是进程崩溃。所以在早期 CPython 版本里把sys.setrecursionlimit调到一个很大的值然后递归压栈崩掉并不是新闻。Python 3.11 之后 CPython 增加了新的 C 递归保护机制同样不鼓励你把上限调到几十万因为解释器只能控制 Python 层递归计数控制不了每个函数栈帧背后真实的 C 栈消耗。1.3 什么时候设置 setrecursionlimit 才合理那setrecursionlimit是不是就绝对不能用了也不是。比如你需要处理一个深度约为 3000 的多叉树默认限制跑不下去但你明确知道业务数据最多到几千层这种情况下可以合理调高import sys sys.setrecursionlimit(10000) def tree_height(node): if node is None: return 0 children_heights [tree_height(child) for child in node.children] return 1 max(children_heights, default0)我需要强调两点经验第一setrecursionlimit要设置成一个有业务依据的值而不是随手写个10**7图省事第二设置完之后务必用一个接近理论最大深度的数据做压测确认不会触发段错误再上线。我自己就见过有人把递归上限调到百万结果真跑到三四十万层时进程直接消失连报错都没有这种线上事故极其难排查。更好的做法是思考能不能从“递归方案”切换到“迭代方案”把深度问题从根上绕开。这一点后面实战部分会展开说。2. 真正的性能杀手是重复计算缓存能把指数级递归拉回线性2.1 fib(40) 的递归为什么三亿多次才算出结果深度限制是硬伤但很多表面正常的递归程序真正的痛点其实是重复计算。最典型的例子就是斐波那契数列教科书里最常见的递归写法calls 0 def fib(n): global calls calls 1 if n 2: return n return fib(n - 1) fib(n - 2) print(fib(30)) # 832040 print(calls) # 约 269 万次你可能会惊讶算fib(30)而已居然调用了 269 万次函数再算一下fib(40)调用次数直接涨到三亿多次。这就是递归树里的“重叠子问题”在作祟——fib(30)会让人去算一次fib(28)fib(29)又会让人去算一次fib(28)同一个结果被反反复复计算了几十万次。平时遇到的项目代码不可能只是数列题但结构是相似的。比如你处理组织架构树时同样的部门节点被多个父节点引用比如解析矩阵网格里的路径数量时同一个子网格在递归里被访问多次。这类代码在数据量小的时候没啥感觉数据规模一上来指数爆炸是肉眼可见的慢。2.2 一件小事就能带来量级提升递归里叠一层缓存既然同一个参数算出的结果永远不变那第一次算完之后把结果记下来之后再遇到就直接从“小本本”里取不重复计算。这就是记忆化在 Python 里最省事的实现是functools.lru_cachefrom functools import lru_cache lru_cache(maxsizeNone) def fib_cache(n): if n 2: return n return fib_cache(n - 1) fib_cache(n - 2) print(fib_cache(100))这段代码算fib(100)是瞬间返回的而用原始递归版本根本等不到结果。原因很简单加了缓存以后每个n对应的计算结果只会真正执行一次后续所有相同参数的调用都直接命中缓存调用次数从指数级降到了线性级。需要提醒的是fib_cache(100)能秒回不代表递归调用链不占栈了。这个函数依然要一路递归到n0如果你改成fib_cache(1200)立刻又会出现RecursionError。这是理解本文主题的关键缓存解决的是重复计算递归深度解决的是栈溢出两者是独立的两件事。2.3 缓存没有抵消递归调用只是让每个问题只算一遍很多人加完缓存以后误以为递归变“轻”了其实函数调用本身的开销并没有少只是每个不同的参数组合只运行一次函数体。什么意思比如你调用fib_cache(100)系统依然需要沿递归链一层层往下调用栈深依然接近 100。缓存真正减少的是函数体里真正执行计算的次数不是调用栈的深度。这就引入一个实际工程里的分组意识遇到递归性能问题时要分清是“重复计算导致指数级耗时”还是“嵌套层数太深导致栈溢出”。前者适合用缓存策略解决后者适合用迭代重写解决。如果你把两个混合在一起很容易出现“加了缓存依然爆栈”“调高限制后依然超时”的迷惑情况。3. 缓存策略怎么选才稳lru_cache 背后的使用边界3.1 从 functools.lru_cache 的参数看缓存策略lru_cache是 Python 标准库自带的装饰器底层实现是 LRU最近最少使用淘汰算法。最常用的两个参数是maxsize和typed。maxsizeNone表示不限制缓存条目数只要函数被调用结果就会永久保存。这种模式适合输入范围有限、重复调用率高的纯函数比如斐波那契、阶乘、组合数计算。maxsize128则意味着缓存只保留最近 128 个不同参数组合的结果超出后会自动淘汰最久没被使用的缓存项。这种模式适合输入组合非常多、但局部重复调用明显的场景。typedTrue会将1和1.0当成两个不同的键因为 Python 整数和浮点数虽然值相等但类型不同。如果函数逻辑对类型敏感需要开启这个参数。还有个小细节是functools.cache是 Python 3.9 之后提供的一个快捷写法等价于lru_cache(maxsizeNone)。但cache没有淘汰机制也没有cache_info()统计方法如果你想看命中率还是得用lru_cache。3.2 函数的“可哈希参数”是缓存生效的前提lru_cache的实现原理是把每次调用的参数打包成缓存 key然后存到字典里。这就意味着函数的参数必须是可哈希的。如果你直接写这样一个版本from functools import lru_cache lru_cache(maxsizeNone) def total(nums): return sum(nums) total([1, 2, 3])运行时会报TypeError: unhashable type: list因为列表是可变对象、不可哈希不能作为字典键。这也是实际开发里最容易踩的坑递归函数如果接收列表、字典、集合这类可变参数直接加lru_cache是会报错的。解决办法通常是先把可变对象转成对应的不可变形式。列表转元组、字典转frozenset(dict.items())比如lru_cache(maxsizeNone) def total_tuple(nums): return sum(nums) total_tuple((1, 2, 3))如果递归函数接收的是自定义对象也需要小心。普通类实例在没重写__eq__的情况下是可以哈希的因为默认按对象 id 哈希但一旦你重写了__eq__却忘记定义__hash__这个类就变成不可哈希了缓存也加不上去。3.3 别把所有递归都无脑加缓存lru_cache虽然好用但前提条件非常明确函数必须是纯函数也就是相同的输入一定产生相同的输出而且函数不依赖外部可变状态。如果你的递归函数里读取了全局变量、文件内容、数据库状态或者依赖当前时间等外部条件那加缓存很可能会得到过期甚至错误的结果。举个很典型的反面例子递归爬取一个带层级结构的业务树每个节点状态会由前端用户实时修改。如果你给“查询节点有效子节点数”这个递归函数加上永久缓存用户改完状态后旧缓存依然生效导致查询结果不更新这种 bug 比慢还难发现。如果是求某个快照区间内的统计值那可以放心缓存如果是实时变化的业务状态缓存策略要注意失效时间或者干脆不要用无上限的缓存。另外对输入范围极大且每个参数只出现一次的递归缓存其实作用有限。比如一个完全不平衡的二叉树每个节点都是唯一路径上的唯一参数那缓存除了占用内存外毫无帮助。判断要不要加缓存核心指标是“重叠子问题数量”够不够多。3.4 用 cache_info 和边界值来决定缓存大小到底设置多少maxsize合适不是拍脑袋决定的。lru_cache提供了两个调试方法cache_info()和cache_clear()。fib_cache.cache_info() # CacheInfo(hits142, misses101, maxsizeNone, currsize101)hits表示命中次数misses表示未命中、真正执行了函数体的次数。如果 misses 数量特别大而 hits 很小说明缓存设置没帮上忙如果 hits 很大但 misses 也持续增大说明输入组合太多无上限缓存可能带来内存风险。这时候限制maxsize就能触发 LRU 淘汰只保留最常用的部分。还有一个实战技巧写完缓存代码以后如果你想对比加缓存前后的性能差异别忘了在测试同一段函数前调用一次cache_clear()清掉上一次运行留下的缓存否则后一次测试会严重虚高。这个细节看起来小却能避免你得出完全错误的结论。4. 实战拆解爆栈的深树和超时的共享子树怎么同时治好4.1 案例一一棵 2000 层深的树递归一到第 1000 层就废了假设我们要计算一棵多叉树的高度用最直观的递归class Node: def __init__(self): self.children [] def make_chain(depth): root Node() current root for _ in range(depth - 1): next_node Node() current.children.append(next_node) current next_node return root def tree_height(node): if node is None: return 0 if not node.children: return 1 return 1 max(tree_height(child) for child in node.children) root make_chain(2000) print(tree_height(root))这段代码会直接抛RecursionError因为实际递归深度达到 2000超过了默认的 1000。很多人可能第一时间想这棵树深度是 2000我设置setrecursionlimit(10000)不就好了确实可以跑但问题在于如果业务数据再往上涨到 5 万层、10 万层你总不可能无休止地调限制。更重要的是这种递归结构本身很脆弱。与其依赖“这个业务最多几千层”这种约定不如直接用递归的子集不更好的思路是用显式栈替代系统调用栈让深度不再受解释器限制。4.2 解法一显式栈把递归改成“人工调用栈”把递归改写成迭代核心思想是自己用一个列表栈来模拟函数调用过程。仍以计算树高度为例常见做法是用后序遍历的方式先处理子节点再处理父节点def tree_height_iter(root): if root is None: return 0 stack [(root, False)] result {} while stack: node, visited stack.pop() if node is None: continue if node in result: continue if visited: if not node.children: result[node] 1 else: result[node] 1 max(result[child] for child in node.children) else: stack.append((node, True)) for child in node.children: if child not in result: stack.append((child, False)) return result[root] deep_root make_chain(2000) print(tree_height_iter(deep_root)) # 2000理解这段代码的关键在于(node, False)和(node, True)两个状态。第一次遇到节点时状态是False只负责把它的子节点压入栈中等所有子节点都计算完毕并写入result字典后再次弹出该节点时状态是True此时可以直接利用result[child]计算当前节点高度。这就是用“人工维护状态”替代“递归调用栈”的核心思路。只要显式栈里的元素是手动入栈出栈的它就不受sys.getrecursionlimit限制树有几百万层也能跑瓶颈只剩内存。实际遇到业务树特别深、同时也不想承担调高限制导致崩溃风险时我优先考虑的就是这种迭代写法。4.3 案例二大量共享子树的 DAG 形结构重复计算拖垮性能深度问题解决了还有一个更隐蔽的问题如果一棵树里大量子节点共享同一个子树递归不加缓存会重复遍历很多次。比如下面这个模拟结构一个根节点下面挂 1000 个分支节点每个分支节点又都指向同一个深度为 100 的共享子树。逻辑上总节点很少但直接递归会让共享子树被反复展开 1000 次。from functools import lru_cache calls 0 class TreeNode: def __init__(self, label): self.label label self.children [] def __repr__(self): return fTreeNode({self.label}) # 构造一个深度为 100 的共享子树 shared_root TreeNode(shared) current shared_root for i in range(99): child TreeNode(fshared-{i}) current.children.append(child) current child # 根节点下挂 1000 个分支每个分支都指向同一个共享子树 root TreeNode(root) for i in range(1000): branch TreeNode(fbranch-{i}) branch.children.append(shared_root) root.children.append(branch) lru_cache(maxsize