Python默认递归深度限制是1000，由sys.getrecursionlimit()返回；虽可用sys.setrecursionlimit()调整，但无法绕过C层栈内存限制，且CPython不支持尾调用优化，尾递归仍会压栈，可靠做法是手动转为while循环。

Python递归深度限制是多少？为什么改不了

Python默认递归深度上限是1000，由sys.getrecursionlimit()返回，用sys.setrecursionlimit()能调高，但治标不治本——C层栈帧仍会爆内存，不是纯Python能绕过的。CPython没做尾调用优化（TCO），写成尾递归形式也**不会自动转成循环**，照样压栈。

手动把尾递归改写成while循环最可靠

别依赖装饰器或trampoline机制，那些只是“模拟”，底层仍是函数调用。真要避免栈溢出，就该人肉拆解逻辑：

• 把递归参数变成循环变量（通常用while条件判断终止）
• 把递归体内的计算逻辑平铺进循环体
• 把原递归的“返回值传递”改成变量更新（如acc = acc * n代替return factorial(n-1, acc*n)）

例如阶乘尾递归版：def fact(n, acc=1): return acc if n → 改成：

def fact_iter(n):
    acc = 1
    while n > 1:
        acc *= n
        n -= 1
    return acc

@tail_call_optimized这类装饰器到底靠不靠谱

这类第三方装饰器（如tail_call_optimized）本质是用异常+栈帧重放模拟TCO，但有硬伤：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

立即学习“Python免费学习笔记（深入）”；

• 无法处理嵌套调用链（比如A→B→C→A），容易陷入无限异常捕获
• 破坏调试体验：traceback里全是装饰器内部的RaiseTailCall帧
• 性能反而更差——每次“尾调用”都触发一次raise和except开销
• PyPy等非CPython解释器行为不可控

什么情况下必须放弃递归思维

当输入规模不确定、且递归深度可能超1000时（比如解析深层嵌套JSON、遍历超深树结构、处理用户上传的任意深度XML），别试图“保递归”，直接上迭代：

• 用显式栈（list）模拟DFS，比递归更可控
• 用队列（collections.deque）做BFS，天然无栈溢出风险
• 对生成器场景，可用yield from配合itertools.chain拼接子生成器，避免深层调用

尾递归在Python里是个幻觉，能不用就不用；能转成循环就立刻转——这是最省心、最不易出错的路径。