不建议靠 sys.setrecursionlimit() 解决递归深度溢出，它只是掩盖问题，易致静默崩溃；应优先排查算法错误、转为迭代或优化数据结构。
直接说结论：不建议靠 sys.setrecursionlimit() 解决递归深度溢出，它只是把问题往后推，容易引发静默崩溃。
为什么 sys.setrecursionlimit() 不是解法而是掩耳盗铃
Python 的调用栈空间是有限的，sys.setrecursionlimit() 只是告诉解释器“允许压多少层函数帧”，但底层 C 栈空间没变。设成 10000 后遇到深度 10001 的递归，照样崩——而且可能不是 RecursionError，而是直接 Segmentation fault 或静默退出，调试更难。
常见错误现象包括：
- 本地能跑通，部署到某些 Linux 服务器就段错误（系统栈默认更小）
- 增加限制后程序变慢、内存占用陡增，甚至卡死
- 多线程环境下，每个线程共享同一限制，但栈空间独立，实际更危险
sys.setrecursionlimit() 的唯一合理使用场景
仅适用于：你**确认递归逻辑本身没问题**，且深度可预测、有明确上界，只是略超默认值（比如稳定在 1200 层），且运行环境可控（如单机脚本、无并发、栈足够大）。
python-flask-vue-creator
下载
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
立即学习“Python免费学习笔记（深入）”；
这时可以临时放宽，但必须配检查和兜底：
- 先用
sys.getrecursionlimit()查当前值 - 设新值时留余量，比如目标深度 1200，设
sys.setrecursionlimit(1500)，别硬顶上限 - 在递归函数入口加深度计数参数 + 显式判断，超限时主动抛异常，而不是等解释器崩
- 避免在库代码或服务中使用，尤其不能写进
__init__.py全局生效
真正该优先做的三件事
遇到 RecursionError: maximum recursion depth exceeded，按这个顺序排查：
-
查是不是算法写错了：比如忘记写 base case、递归调用参数没缩小（
factorial(n)调自己而不是factorial(n-1)）、树遍历没判空节点 -
看能不能转成迭代：阶乘、斐波那契、DFS 遍历都可改
while+ 变量或list模拟栈；数独回溯、目录扫描这类，用显式栈比隐式调用栈更可控 -
评估是否真需要深递归：比如解析嵌套 JSON 或 XML，深度超 100 层基本说明数据结构设计反模式，应改用流式解析（
json.JSONDecoder().raw_decode或xml.sax）
最常被忽略的一点：递归深度问题往往不是“不够深”，而是“不该深”——函数在重复做同一件事，或状态没收敛。先打开 sys.settrace 打几行日志看看调用链，比盲目调大限制有用得多。
