不能直接调高sys.setrecursionlimit，因其仅修改python层计数器，不扩大底层c栈空间，盲目上调易致段错误、内存耗尽或跨平台失效；应优先重构为迭代、生成器或缓存。
RecursionError 出现时，为什么不能直接调高 sys.setrecursionlimit
RecursionError 本质是 Python 解释器在函数调用栈帧数量超过 sys.getrecursionlimit() 时主动抛出的保护机制。默认值约 1000，不是随意定的——它对应着底层 C 栈空间的安全余量。盲目设成 5000 或 10000，不会让递归“更健壮”，只会让崩溃从可捕获的异常变成不可预测的段错误。
- 操作系统线程栈有硬限制（Linux 默认 8MB，Windows 约 1MB），
sys.setrecursionlimit()只改 Python 层计数器，不扩大真实栈空间 - 每层递归至少压入一个栈帧（含局部变量、返回地址等），深度翻倍，栈内存几乎线性增长；设到 50000 后，单层均摊 100 字节就吃掉 5MB，极易触发
Segmentation fault - 多线程下，所有线程共享同一 limit 值，但各自栈空间独立——某个线程栈小（如某些容器环境），照样崩，且无 traceback
- PyPy、Jython 等解释器不遵循该设置，代码移植即失效
哪些错误现象说明你已经在靠 sys.setrecursionlimit 掩盖问题
真正该警觉的，不是报错本身，而是报错出现的上下文：
- 本地跑通，CI 或生产环境（尤其是 macOS / Alpine Linux 容器）直接 segfault，
strace显示--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL} - 加大 limit 后程序变慢、RSS 内存陡增，甚至卡死——说明栈空间正在挤占堆或其他线程资源
-
pytest测试中仅开启--tb=short就崩，关掉反而正常——说明 traceback 收集本身已逼近栈上限 -
mock.patch对象或自定义<strong>repr</strong>被反复调用，形成隐式递归链（比如 mock dict 的 value 指向自身） - 同一函数名在 traceback 最后几帧重复出现（如
parse_node→parse_node→parse_node），但参数没收敛，base case 实际未生效
什么时候真能安全调 sys.setrecursionlimit？必须满足这三点
只有同时满足以下全部条件，才可考虑微调：
- 已确认递归逻辑正确：有明确 base case、参数严格收敛、无循环引用或副作用（如
<strong>repr</strong>触发再进入） - 深度可预估且稳定：输入规模固定（如解析深度 ≤ 2000 的语法树）、不依赖用户输入或外部数据嵌套层级
- 运行环境可控：单线程脚本、非容器部署、已用
resource.getrlimit(resource.RLIMIT_STACK)验证过栈余量足够
即便如此，也必须：
- 用
try/except RecursionError包裹调用，并在finally中恢复原 limit - 在递归入口加显式深度计数参数，超限时主动 raise 带信息的异常，而不是等解释器崩
- 绝不写进库代码、
<strong>init</strong>.py或服务启动脚本——调用方无法预期，兼容性灾难
比调限更靠谱的替代方案：迭代、生成器、缓存
90% 的 RecursionError 场景，重构比调参更稳：
- 树/图 DFS：用
list或collections.deque模拟栈，把dfs(node.left)拆成stack.append(node.left) - 分治类（如快排）：维护待处理区间列表，避免左右子递归嵌套，改用
while intervals:循环 - 需要回溯路径：把
path改为循环内可变列表，用path.append()/path.pop()替代函数参数传递 - 斐波那契、AST 表达式求值等重复子问题：加
@lru_cache，深度不变，调用次数骤降 - 中间结果需逐条消费：改用生成器 +
yield from，避免整棵树展开进内存
真正难处理的，是那些既深度大、又无法缓存、还强依赖调用栈隐式状态的递归——这时候调限不是捷径，而是最后手段，且必须同步调大线程栈（threading.stack_size()）并做压力测试。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
