RecursionError是CPython为防止栈溢出而设的安全机制，触发条件是调用栈总字节数超限而非单纯递归次数多；其默认限制由系统栈大小估算得出，盲目调高sys.setrecursionlimit()易致段错误。
RecursionError 不是 bug，而是 Python 主动拦截栈溢出的安全机制；盲目调高 sys.setrecursionlimit() 很可能让程序从报错变成直接崩溃。
RecursionError 的真实触发条件是什么
Python 默认递归深度限制不是固定值，而是由 CPython 解释器在启动时根据系统栈大小估算出来的安全阈值（通常为 1000 左右，可通过 sys.getrecursionlimit() 查看）。它防的不是“递归次数多”，而是“调用栈总字节数超限”。
常见误判场景：
- 你以为是算法太深 —— 实际可能是
__str__或__repr__打印对象时隐式触发自身，形成链式递归 - 你以为改了 limit 就能跑通 —— 实际在 Linux 容器里线程栈只有 2MB，设到 5000 层就段错误（
Segmentation fault） - 你处理的是用户上传的嵌套 JSON —— 深度完全不可控，哪怕只设到 2000，输入一个 3000 层的结构照样崩
什么时候可以谨慎调 sys.setrecursionlimit()
仅当同时满足以下全部条件时，才考虑临时上调：
立即学习“Python免费学习笔记（深入）”；
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 递归逻辑已确认无死循环，base case 正确且参数严格收敛（比如每次
n-1或node.left） - 输入规模明确、稳定、可预期（例如：处理固定 1500 节点的树，理论最大深度约 11，但代码写成了线性递归）
- 运行环境内存充足，且非多线程服务（子线程栈更小，
setrecursionlimit()对其无效） - 上调幅度保守，比如从 1000 → 1500，并配
try/except RecursionError兜底
绝对不要在生产服务启动时无条件执行 sys.setrecursionlimit(10000) —— 这等于把安全带剪掉再踩油门。
哪些递归函数必须重构成迭代
以下模式一旦输入规模稍大（> 500），几乎必然触发 RecursionError，且重构收益极高：
- 树/图遍历类：如
inorder(root)、dfs(node)，原写法隐式压栈，改成显式stack列表后空间可控 - 尾递归结构：如
factorial(n, acc=1)、fib_tail(n, a=0, b=1)，直接拆成while循环，零栈开销 - 含中间容器拼接的：如
return f(left) + [val] + f(right)，不仅深，还产生大量临时 list，改用生成器或预分配更稳
关键不是“能不能转”，而是“不转就只能卡在 1000 层不敢上线”。
属性定义引发的 RecursionError 最容易被忽略
这不是算法问题，是命名冲突导致的无限自调用：
错误写法：
@property
def id(self):
return self.id # ❌ self.id 触发同一 getter，立刻死循环
正确写法：
def __init__(self):
self._id = 42
<p>@property
def id(self):
return self._id # ✅ 访问私有字段，不触发 property
所有自定义 @property 的 getter/setter 内部，只要出现 self.xxx 且 xxx 是同名属性，就立即中招。这类错误不会出现在调用栈里显示“递归太深”，而是一上来就爆 RecursionError，排查时容易绕远。
