直接调大 sys.setrecursionlimit 不能真正解决递归深度问题，反而容易引发栈溢出崩溃——它只是把“爆栈”从报错变成静默崩溃。
直接调大 sys.setrecursionlimit 不能真正解决递归深度问题，反而容易引发栈溢出崩溃——它只是把“爆栈”从报错变成静默崩溃。
为什么 sys.setrecursionlimit 不是安全解法
Python 默认递归限制约 1000 层，sys.setrecursionlimit 只是修改解释器层面的计数阈值，并不增加 C 栈空间。一旦实际调用深度超过系统线程栈大小（通常几 MB），进程会直接 segmentation fault 或被 OS 杀死，不会抛出 RecursionError。
- Windows 下常见崩溃提示：
Windows fatal exception: stack overflow - Linux/macOS 下可能直接
Killed: 9退出，无 traceback - 多线程环境下，每个线程栈独立，
setrecursionlimit对子线程无效
什么情况下可以谨慎调用 sys.setrecursionlimit
仅适用于：递归逻辑本身正确、深度可预估、且远低于系统栈上限的场景，比如解析深度可控的嵌套 JSON 或 AST 节点遍历。
- 必须配合
try/except RecursionError做兜底，不能只信设置值 - 建议增量调整并压测，例如从
sys.setrecursionlimit(3000)开始，观察是否稳定 - 生产环境应记录原始限制和新值：
print(f"RLIMIT before: {sys.getrecursionlimit()}")
更可靠的替代方案：把递归转成迭代
绝大多数递归（尤其是尾递归或树形遍历）都能用显式栈模拟。以经典二叉树中序遍历为例：
立即学习“Python免费学习笔记（深入）”；
# 递归写法（易爆栈）
def inorder_recursive(node):
if not node:
return
inorder_recursive(node.left)
print(node.val)
inorder_recursive(node.right)
<h1>迭代写法（可控、不依赖系统栈）</h1><p>def inorder_iterative(root):
stack, result = [], []
node = root
while stack or node:
while node:
stack.append(node)
node = node.left
node = stack.pop()
result.append(node.val)
node = node.right
return result
- 迭代版本内存开销明确（栈里最多存树高个节点），不会意外崩掉
- Python 没有尾递归优化，所以哪怕写成尾递归形式，也得手动转迭代
- 对 DFS 类算法，用
collections.deque替代 list 做栈，避免pop(0)的 O(n) 开销
需要深层递归时的务实选择
如果业务逻辑确实无法避免深递归（如某些符号计算、超深嵌套配置合并），优先考虑：
- 改用 PyPy：其栈管理更灵活，对深递归容忍度更高
- 拆分任务：用
concurrent.futures.ThreadPoolExecutor把大递归切片，每片控制在 500 层内 - 换语言接口：将核心递归逻辑用 Rust/Cython 实现，绕过 CPython 栈限制
真正棘手的不是“怎么调高限制”，而是识别哪些递归本就不该存在——检查调用链里是否有隐式递归（比如 __getattr__ 触发自身）、或重复构造相同子问题（该上缓存或动态规划了）。
