recursionerror本质是控制流失控，需优先排查pytest/mock/repr等环境放大效应及循环引用，而非调高limit；真递归应转迭代并加深度防护。
直接调大 sys.setrecursionlimit() 不能解决环境崩溃，反而大概率让进程在 CI/容器里静默被 Killed: 9 或触发 Segmentation fault——它只是把报错换成更难排查的底层崩溃。
RecursionError 出现在测试或部署环境时，先别改 limit
这类崩溃往往不是“真需要深递归”，而是环境放大了副作用：
-
pytest自身的断言包装、fixture 链、mock.patch对象会额外增加调用帧，原本 950 层的递归在测试中就超限 -
__repr__或__str__实现里不小心打印了自身（比如return f"Node({self.children})"），一触发失败断言就无限展开 - JSON/YAML 解析器遇到用户提交的超深嵌套结构（如 2000 层 dict 嵌套），而代码没做深度防护
- CI 容器默认栈更小（
ulimit -s常为 4096 KB），比本地开发机更容易爆栈
确认是不是真递归：用 traceback 快速定位源头
在报错位置加两行调试，不依赖完整 traceback：
import sys, traceback
print("Current depth:", len(traceback.extract_stack()))
print("Last 3 frames:", traceback.extract_stack()[-3:])
观察输出：
- 如果帧名反复出现同一函数（如
parse_config→parse_config），是真实递归逻辑问题 - 如果帧里混着
_pytest、mock、__repr__，优先删掉这些实现或禁用详细 traceback：pytest --tb=no - 用
gc.get_referrers(obj)检查对象是否被循环引用，尤其 mock 后又存进字典的场景
必须调 limit 时，只在最小作用域内设且配兜底
全局设置 sys.setrecursionlimit(10000) 是高危操作，尤其多线程服务中子线程栈更小。安全做法是：
- 仅在触发递归的模块顶部或函数入口处临时设置，用
try/finally恢复原值 - 先查系统栈上限：
import resource; resource.getrlimit(resource.RLIMIT_STACK)（Unix） - 按每层约 1–2 KB 估算：4 MB 栈 ≈ 安全上限 2000–3000 层，设
sys.setrecursionlimit(2500)而非 10000 - 必须同步调大主线程栈（Linux/macOS）：
import threading; threading.stack_size(8 * 1024 * 1024)，否则 limit 再高也无用
真正该重构的几类递归场景
以下情况几乎从不该用递归，转迭代后既稳定又易测：
- 树遍历（DFS/BFS）：用
list或collections.deque存(node, state)元组，显式管理访问顺序 - 路径解析（如
os.walk自定义变体）：改用栈 + while 循环，避免符号链接环或深度嵌套导致失控 - 嵌套结构解析（JSON/XML/AST）：加深度计数器，超限时抛
ValueError或截断，而不是硬扛 - 回溯算法（N 皇后、数独）：用栈存当前路径和可选分支，每次 pop 一个状态推进，避免隐式栈累积
最危险的不是调限本身，而是把 RecursionError 当成配置问题来处理——它通常意味着控制流已脱离预期，而静默崩溃比报错更难定位。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
