RecursionError是Python解释器主动拦截而非内存耗尽，因默认递归深度限制约1000层，超限即抛异常；根本解法是改用迭代，慎用sys.setrecursionlimit()。
为什么递归会爆栈，而不是内存耗尽？
Python 报 RecursionError: maximum recursion depth exceeded 时，不是因为内存不够，而是解释器主动拦截——它检测到调用栈帧数量超过 sys.getrecursionlimit()（默认约 1000 层），就直接抛错。这是 CPython 的安全机制，防止无限递归拖垮整个进程。
常见踩坑点：
- 误以为提高
sys.setrecursionlimit(10000)就能“解决问题”，实际可能触发底层 C 栈溢出，导致 Python 进程直接段错误崩溃 - 在树遍历、JSON 解析、AST 遍历等场景中，嵌套深度轻松超 1000，但开发者仍写递归，没做兜底
- 把尾递归当“性能解药”，却不知道 CPython 完全不优化尾调用，
@tail_call_optimized类装饰器只是用异常模拟跳转，破坏调试、变慢、不可靠
什么时候必须改用迭代？哪些递归最容易爆栈？
非尾递归、多路递归、无显式深度控制的递归，优先转迭代。比如树的前/中/后序遍历、DFS 搜索、回溯生成全排列——它们天然需要保存“当前节点 + 已处理子树状态”，但隐式调用栈无法中断或限深。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
list或collections.deque模拟栈，把“待处理节点”和“执行上下文”一起存进去，例如中序遍历需压入(node, 'left_done')标记 - DFS 迭代版注意子节点入栈顺序：
stack.append(node.right); stack.append(node.left)才能保证左先访问 - 加一层深度计数：在循环里维护
depth变量，一旦超阈值（如 500）就break或抛自定义异常，比等RecursionError更可控
哪些优化能真正提速，又不碰栈限制？
纯递归改迭代是防爆栈的主干，但若逻辑本身含大量重复计算（如朴素 fibonacci(n)），光改迭代还不够，得配合缓存或数学降维。
有效组合：
-
@lru_cache(maxsize=None)对有重叠子问题的递归极有效，比如动态规划类函数；但注意缓存键必须可哈希，且不要用于带副作用或大对象参数的函数 - 尾递归形式（如阶乘、链表翻转）可直接拆成单变量循环，
a, b = b, a + b这类更新比递归快一个数量级，也彻底规避栈问题 - 对超大规模输入（如
n > 10^6的斐波那契），考虑闭式公式或矩阵快速幂，避免任何线性过程
递归没坏，但你得知道它在哪条线上运行
递归本身没问题，问题出在默认栈限制 + 无防护的调用方式。真正关键的不是“能不能递归”，而是“是否允许调用深度脱离控制”。哪怕只用一次 sys.setrecursionlimit()，也该同步加 try/except 捕获 RecursionError 并 fallback 到迭代路径——这比事后 debug 崩溃日志快得多。
