sys.setrecursionlimit不是解药而是临时止痛片，仅调高阈值不扩展系统栈空间，超os栈大小会致不可捕获的崩溃；应优先重构为迭代、预检深度、按需设限并及时复位。
为什么不能无脑调高 sys.setrecursionlimit
调高递归限制不是“解药”，而是临时止痛片。Python 默认递归深度约 1000，底层依赖 C 栈帧，sys.setrecursionlimit 只是修改 Python 解释器的计数阈值，并不扩展系统栈空间。一旦真实调用深度超过 OS 线程栈大小（Linux 默认 8MB，Windows 约 1MB），会直接触发 Segmentation fault 或静默崩溃——这种错误不抛 RecursionError，无法捕获，调试极难。
常见误操作包括：在生产环境启动时固定设为 100000、在递归函数入口无条件加一层 setrecursionlimit、或把该调用和算法优化混为一谈。
先确认你真需要深层递归
90% 的所谓“深层递归需求”其实源于数据结构设计或遍历逻辑缺陷。比如树的深度优先遍历写成纯递归，而实际可用显式栈模拟；又如解析嵌套 JSON 或 AST 节点时，未做深度预检就递归下降。
- 用
sys.getrecursionlimit()查当前值，再用len(inspect.stack())在可疑位置打点，看真实调用链长度 - 对输入做前置校验：如树结构先跑
max_depth = max(len(path) for path in all_paths(root))（用 BFS/迭代实现） - 优先改写为迭代：用
list或collections.deque模拟栈，把状态存为元组(node, depth, context)
sys.setrecursionlimit 的安全使用边界
仅在明确知道输入规模上限、且无法重构为迭代时才考虑微调。安全做法是“按需设、用后复位”，而非全局永久提升。
- 设限前先估算：若最坏情况深度为 N，建议设为
min(N * 2, 10000)，绝不超 15000（CPython 在多数系统上已逼近危险区） - 用
try/finally保证恢复：old_limit = sys.getrecursionlimit() sys.setrecursionlimit(5000) try: result = deep_recursive_func(data) finally: sys.setrecursionlimit(old_limit) - 避免多线程中调用：该设置是进程级的，线程间共享，可能干扰其他逻辑
替代方案比调限更可靠
真正健壮的深层处理几乎从不依赖 sys.setrecursionlimit。例如：
- 用
functools.lru_cache缓存中间结果，减少重复递归分支（适合重叠子问题） - 对递归函数做尾递归检测 + 手动转为循环（虽 Python 不优化尾递归，但可人工展开）
- 用
trampoline模式：函数返回下一个要调用的函数和参数，主循环驱动，完全脱离调用栈 - 对超深嵌套数据（如千层 JSON），改用
json.loads(text, parse_int=..., parse_float=...)配合自定义解析器，避免递归解析器
递归深度失控往往是信号——说明控制流或数据建模出了问题，而不是解释器不够宽容。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
