直接调大 sys.setrecursionlimit() 不能真正解决递归崩溃问题，反而可能引发段错误或内存耗尽——它只是把“炸点”往后挪，没修炸药引信。
直接调大 sys.setrecursionlimit() 不能真正解决递归崩溃问题，反而可能引发段错误或内存耗尽——它只是把“炸点”往后挪，没修炸药引信。
为什么改 sys.setrecursionlimit() 很危险
CPython 的栈空间默认由操作系统线程栈限制（Linux 通常 8MB，Windows 约 1MB），而 sys.setrecursionlimit() 只控制 Python 层面的计数器。一旦实际调用深度超过底层栈容量，进程会直接 Segmentation fault 或被 OS 杀掉，不抛异常、不给 traceback。
- 设成
100000后，在递归函数里每层压入 200 字节局部变量，就轻松吃掉 20MB 栈空间 → 崩溃 - 多线程环境下，每个线程有自己的 C 栈，但
sys.setrecursionlimit()是全局生效 → 某个线程栈小，照样崩 - PyPy、Jython 等解释器不遵循该设置，代码移植即失效
什么情况才该考虑调这个值
仅当确认是「纯 Python 层计数器先到上限」，且递归深度确实在安全范围内（比如 ≤ 5000）、无深层嵌套对象或大局部变量时，才可微调。
- 典型场景：解析深度 ≤ 2000 的树形 JSON，用朴素递归遍历，报
RecursionError: maximum recursion depth exceeded - 安全做法：先用
resource.getrlimit(resource.RLIMIT_STACK)查当前栈上限，估算单层开销，再设为min(新值, 栈字节数 // 单层均摊) - 必须配
try/except RecursionError回退逻辑，不能假设设置后就万事大吉
比调限更靠谱的三种替代方案
绝大多数递归崩溃，本质是算法没做尾调用优化或未转迭代——优先重构，而非硬扛。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
-
手动转迭代：用
list或deque模拟调用栈，尤其适合 DFS、树遍历。例如原递归def dfs(node): ... dfs(node.left); dfs(node.right)→ 改为stack = [root]; while stack: node = stack.pop(); ... stack.extend([node.right, node.left]) -
生成器 +
yield from：对需返回中间结果的递归（如遍历路径），用生成器避免栈累积，调用方逐条消费，内存可控 -
使用
functools.lru_cache减少重复递归分支：像斐波那契这种指数级重复计算，加缓存后深度不变但调用次数骤降，间接规避深度问题
真要调，必须同步做的三件事
如果业务强依赖深度递归（如某些符号计算、AST 重写），且已排除迭代可能，那么调限不是终点，而是起点。
- 用
threading.stack_size(32*1024*1024)主动扩大主线程栈（Linux/macOS 有效，Windows 无效） - 在递归函数入口加深度检查：
if len(inspect.stack()) > 800: raise RuntimeError("Too deep, aborting")，留出缓冲余量 - 部署时用
ulimit -s预设 shell 进程栈上限，否则容器或 systemd 服务里仍受限
递归深度问题从来不是数字游戏。真正健壮的代码，会在栈溢出前就感知到风险，并切换策略——而不是等到 Segmentation fault 才发现，连日志都来不及打。
