递归深度超限会直接报RecursionError，因CPython设1000层硬限制防栈溢出；调高限制易致进程崩溃，应改递归为迭代，用列表模拟栈并保存完整状态。
为什么递归深度超限会直接报 RecursionError？
Python 默认递归限制是 1000 层（可通过 sys.getrecursionlimit() 查看），一旦函数调用栈深度超过该值，解释器会主动抛出 RecursionError: maximum recursion depth exceeded。这不是内存耗尽，而是 CPython 解释器的硬性保护机制——它防止无限递归拖垮整个进程。关键点在于：这个限制作用于所有递归调用链总深度，包括你没意识到的间接递归（比如 A → B → A）。
-
sys.setrecursionlimit()可以调高，但不推荐：设太高可能触发底层 C 栈溢出，导致 Python 进程直接崩溃（SIGSEGV），比抛异常更糟 - 真正安全的做法是避免依赖深层递归，而非强行撑高限制
把递归改写成迭代时，栈结构怎么模拟？
多数递归（尤其是树遍历、DFS、分治类）本质是维护一个待处理任务栈。手动用 Python 列表模拟即可，list.append() 和 list.pop() 能高效实现 LIFO。
常见错误是只存“当前值”，漏掉递归中隐含的状态变量。例如斐波那契递归 f(n) 需要两个子状态 f(n-1) 和 f(n-2)，迭代时就得存 (n, 'pending') 或拆成带上下文的元组。
- 用
stack = []替代函数调用栈，每轮pop()一个任务，处理后append()新任务 - 如果原递归有多个分支（如二叉树左右子树），按需顺序
append()，注意顺序是否影响结果（DFS 先左后右 vs 先右后左） - 对带返回值的递归（如求和、路径拼接），需额外用字典或命名元组缓存子结果，避免重复计算
示例：朴素递归阶乘
立即学习“Python免费学习笔记（深入）”；
def fact(n):
return 1 if n <= 1 else n * fact(n-1)
迭代等价写法：
def fact_iter(n):
result = 1
while n > 1:
result *= n
n -= 1
return result
——这里根本不需要显式栈，因为是尾递归，可直接转循环。
尾递归优化在 Python 中为什么基本无效？
CPython 完全不支持尾递归优化（TCO），即使你把递归写成尾调用形式（最后一句是纯函数调用），解释器仍会层层压栈。例如：
def tail_fact(n, acc=1):
return acc if n <= 1 else tail_fact(n-1, n*acc) # 尾递归形式运行时依然会累积栈帧，tail_fact(2000) 同样触发 RecursionError。别信网上“加装饰器就能 TCO”的方案——那些装饰器只是用迭代重写逻辑，本质还是手动转循环，并非解释器级优化。
- 所有声称“启用 Python 尾递归”的方案，底层都是把调用栈换成列表模拟，不是真正省栈空间
- 如果业务逻辑天然适合尾递归（如链表遍历、累加器模式），直接重写为
while循环更清晰、更可靠
什么情况下必须保留递归？怎么控制深度？
某些场景递归语义更自然且难以扁平化：比如解析嵌套 JSON、正则回溯、AST 遍历。这时不能一刀切禁用，而要主动管控深度。
- 在递归函数开头加深度检查：
if depth > MAX_DEPTH: raise RuntimeError("Too deep")，比让解释器崩掉更可控 - 对输入做预检：如解析 JSON 前用
json.loads(s, parse_constant=lambda x: ...)拦截过深嵌套；处理树结构前先用 BFS 统计最大深度 - 使用生成器 +
yield from分批处理，把单次深层递归拆成多次浅层调用，配合外部循环消费
递归本身不是问题，失控的调用深度才是。真正要盯住的，是输入规模与递归分支因子的乘积——这才是栈空间消耗的真实源头。
