直接调高 sys.setrecursionlimit() 不能修复 recursionerror，反而易致程序被 kill -9 或段错误；真正需修复的是递归失控源头，如 mock 引发的隐式递归、无深度防护的 json 解析等，并优先重构为迭代。
直接调高 sys.setrecursionlimit() 不能修复 RecursionError，反而大概率让程序在 CI 或容器里静默被 kill —9 或触发 segmentation fault。真正要修的，是递归失控的源头。
RecursionError 真实触发点常不在你的函数里
报错堆栈里反复出现 __repr__、mock.patch、_pytest 或 json.loads？那大概率不是你写的递归逻辑真需要 2000 层，而是环境放大了副作用：
- 测试中
mock对象被存进字典，断言失败时触发__repr__→ 又打印自身 → 再次触发__repr__，形成隐式链式递归 - 用户提交了 3000 层嵌套的 JSON，而你的解析代码没做深度防护，
json.loads()递归展开时直接撞上限 - CI 容器默认栈大小只有 4 MB（
ulimit -s），本地能跑通的 1500 层递归，在线上直接段错误 - 用
traceback.extract_stack()快速确认：如果最后几帧全是同一函数名（如parse_node→parse_node），才是真递归；如果混着Mock、assertEqual，优先删掉或禁用相关 repr
必须改 limit 时，只在最小作用域内临时设且配兜底
全局执行 sys.setrecursionlimit(10000) 是高危操作，尤其多线程服务中子线程栈更小，该设置对其无效。安全做法是：
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 先查系统栈上限：
import resource; resource.getrlimit(resource.RLIMIT_STACK)（Unix/macOS） - 按每层约 1–2 KB 估算：4 MB 栈 ≈ 安全上限 2000–3000 层，设
sys.setrecursionlimit(2500)而非 10000 - 仅在触发递归的函数入口处设置，并用
try/finally恢复原值：old = sys.getrecursionlimit() sys.setrecursionlimit(2500) try: result = my_deep_func(data) finally: sys.setrecursionlimit(old) - 若主线程栈本身受限（Linux/macOS），还需同步调大：
import threading; threading.stack_size(8 * 1024 * 1024)
绝大多数场景该重构为迭代，而非调参
树遍历、路径解析、回溯求解（如数独）、DFS/BFS —— 这些都不是“必须递归”的场景。显式用 list 或 collections.deque 管理状态，既规避深度限制，又易调试、易加超时和深度防护：
- DFS 示例：把
def dfs(node): ... dfs(node.left) ...改成stack = [(node, 0)]; while stack: node, depth = stack.pop(); if depth > 100: raise ValueError("too deep") - JSON 解析防爆：用
json.load()前加深度钩子，或换用ijson流式解析，避免一次性加载深层嵌套结构 - 阶乘、斐波那契等线性递归：直接用循环，空间复杂度从 O(n) 降到 O(1)，且无栈风险
- 尾递归变体（如带 accumulator 的
factorial(n, acc=1)）：Python 不优化尾调用，仍压栈，不如直接转循环
真正难处理的是那些无法预估深度、又必须逐层展开的场景（比如解析用户可控的嵌套模板），这时得靠生成器分块、限深递归 + fallback 机制，或者引入 trampolines 类库 —— 但第一反应不该是调 setrecursionlimit，而是问：这个结构本该由谁来约束？
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
