盲目调高sys.setrecursionlimit通常不是好主意，因其仅掩盖递归算法结构性缺陷，可能引发崩溃且不解决内存线性增长问题；应优先改用迭代或修复逻辑。
为什么改 sys.setrecursionlimit 通常不是好主意
Python 默认递归深度限制是 1000 左右，触发 RecursionError 很可能说明算法本身存在结构性问题，而非“不够深”。盲目调高限制只是掩盖栈溢出风险，还可能引发解释器崩溃（尤其是 C 扩展或嵌入式环境），且对内存消耗无实质改善。
常见错误现象：RecursionError: maximum recursion depth exceeded while calling a Python object 出现在处理深层嵌套结构（如树遍历、JSON 解析）、未收敛的递归逻辑（比如漏写 base case 或条件判断错误）时。
- 递归深度每增加一层，就多压一个栈帧，内存占用线性增长；调高限制只是推迟崩溃，不解决根本问题
- 某些平台（如 macOS 的某些 Python 构建版本）对栈大小有硬限制，
sys.setrecursionlimit超过一定值（如 50000）可能直接 segfault -
sys.setrecursionlimit是全局设置，影响整个解释器生命周期，其他模块可能依赖默认行为
哪些场景真能安全用 sys.setrecursionlimit
极少数情况下可以临时放宽限制，但必须满足：已确认递归逻辑正确、深度可预估、且不涉及用户输入或外部数据驱动的嵌套层级。
典型使用场景：解析固定深度的配置文件、遍历已知规模的语法树、单元测试中构造可控深度的递归调用链。
立即学习“Python免费学习笔记（深入）”；
- 务必配合
try/except捕获RecursionError，防止失控 - 设置后建议用
sys.getrecursionlimit()验证是否生效 - 避免在库代码中修改该值——调用方无法预期，易引发兼容问题
- 示例：
import sys old_limit = sys.getrecursionlimit() sys.setrecursionlimit(3000) try: result = my_deep_recursive_func(data) finally: sys.setrecursionlimit(old_limit) # 恢复原值
用迭代替代递归：以 DFS 为例
绝大多数递归可转为显式栈 + 循环，既规避深度限制，又更易调试和控制资源。以深度优先搜索（DFS）为例，递归写法容易在图/树过深时崩，而迭代版完全可控。
关键差异在于：递归隐式使用调用栈，迭代显式维护一个 stack 列表或 deque，每次 pop 一个节点并 push 其子节点。
- 原递归 DFS 常见写法：
def dfs(node): if not node: return; process(node); dfs(node.left); dfs(node.right) - 等价迭代写法：
stack = [root]; while stack: node = stack.pop(); process(node); if node.right: stack.append(node.right); if node.left: stack.append(node.left) - 注意子节点入栈顺序（left/right）决定遍历方向，和递归调用顺序严格对应
- 若需保留递归中的局部变量状态，可在栈中存元组：
stack.append((node, local_state))
尾递归优化？Python 不支持，别白费劲
有人试图用装饰器模拟尾递归优化（TCO），比如通过抛异常跳转重置栈帧。这在 Python 中不可靠：CPython 明确不支持 TCO，且这类 hack 会破坏调试信息、干扰性能分析工具，还可能与 try/except、生成器、上下文管理器冲突。
真实约束来自 CPython 的实现机制——函数调用必然新建栈帧，没有编译期优化空间。
- 不要用
@tail_call_optimized类装饰器处理生产逻辑 - 即便手动改写为循环，也比依赖装饰器更清晰、更易测、更少副作用
- 如果算法天然适合尾递归（如累加、尾部列表处理），直接写成 while 循环 + 状态变量，几行搞定
实际遇到 RecursionError，先检查 base case 是否覆盖所有分支、递归参数是否真在收敛；再看数据结构深度是否合理；最后才考虑是否值得迭代改写。强行调高限制，就像给漏水的船加高船沿——水位一涨，照样沉。
