Python 3.11 未支持尾递归优化，RecursionError 源于 CPython 栈帧累积超限；应优先将 dfs、嵌套字典展开、回溯等递归转为显式栈迭代，仅在必要时谨慎调高 recursion limit。
Python 3.11 没有引入尾递归优化，sys.setrecursionlimit() 仍是危险的权宜之计；真正有效的优化路径是识别递归模式、提取状态、用显式栈重写——绝大多数爆栈问题都能靠迭代解决。
为什么 Python 3.11 还是会 RecursionError
CPython 解释器（包括 3.11）依然不支持尾调用优化（TCO），所有递归调用都生成新栈帧。默认 sys.getrecursionlimit() 是 1000，一旦实际调用深度超过该值，立刻抛出 RecursionError: maximum recursion depth exceeded。这不是性能问题，而是解释器主动拦截——防止 C 层栈溢出导致进程崩溃。
常见误判包括：
- 以为“3.11 更快所以能撑更深”，实际栈限制没变，只是局部变量分配稍快
- 把
@lru_cache当成栈安全方案：它只加速重复计算，不减少调用深度 - 在异步函数里用递归（如
async def f(): await f()），同样受同一限制，且更难调试
哪些递归必须转迭代？看这三类典型场景
不是所有递归都值得保留。以下模式在 Python 中极易爆栈，且转迭代成本低、收益明确：
立即学习“Python免费学习笔记（深入）”；
-
dfs_recursive(node)类树/图遍历：每层压两个子节点，深度线性增长 → 改用stack = [root]+while stack: -
flatten_dict(d)处理嵌套字典：深层嵌套 JSON 常见于配置解析、API 响应 → 改用stack = list(d.items())循环展开 -
find_all_paths(graph, start, end)回溯搜索：需维护路径状态 → 入栈时存元组(current_node, current_path)，而非只存节点
关键点：入栈顺序要和原递归调用顺序相反。例如前序遍历递归先处理左再右，迭代就得先 stack.append(right) 再 stack.append(left)，保证 left 先被 pop()。
迭代改写三步法：以二叉树中序遍历为例
原递归写法：
def inorder_recursive(node):
if not node:
return
inorder_recursive(node.left)
print(node.val)
inorder_recursive(node.right)
改成迭代只需三步：
-
提取状态：当前节点
node是核心变量；还需记录“是否已访问过左子树”——这不能丢，否则逻辑错乱 -
设计栈元素：用元组
(node, visited_left)，初始为(root, False) -
手动展开递归体：
stack = [(root, False)] while stack: node, visited_left = stack.pop() if not node: continue if visited_left: print(node.val) stack.append((node.right, False)) else: stack.append((node, True)) stack.append((node.left, False))
注意：这里用了两次 append 模拟“先左后根”的顺序，且中间插入了状态标记。比单纯压节点多一维信息，但完全可控。
真要调 sys.setrecursionlimit()？先做这三件事
仅当确认业务强依赖递归（如解析 AST、数学归纳定义）、且无法重构时，才考虑临时调限。但必须同步完成：
- 用
resource.getrlimit(resource.RLIMIT_STACK)（Linux/macOS）或threading.stack_size()查当前线程可用栈空间，按「每层约 1–2 KB」反推安全上限 - 在
if __name__ == '__main__':最早位置设置，并用try/except RecursionError包裹调用，失败后立即恢复原 limit - 禁用所有可能引入隐式递归的机制：自定义
__getattr__、日志装饰器、异常链中的递归格式化逻辑
最易被忽略的是：Python 3.11 的 ExceptionGroup 和 except* 在嵌套异常构造时可能意外加深调用栈，调试时需用 inspect.stack() 实测真实深度。
