应改用迭代或显式栈替代递归，因cpython无尾调用优化，递归深度超限必抛recursionerror；orm链式加载、树形结构等场景易触发该错误，显式栈可控且可加深度限制，而lru_cache和yield生成器均无法解决栈深问题。
直接改用迭代或显式栈，别碰 sys.setrecursionlimit —— 它只是把爆栈时间往后拖，反而容易在生产环境突然崩掉。
递归查询为什么会触发 RecursionError
Web 开发里常见场景：ORM 关系链式加载（比如 user.profile.department.parent.parent）、树形结构无限展开（如评论嵌套、菜单递归渲染）、或自定义的递归 API 路由解析。这些操作一旦深度超过 Python 默认的 ~1000 层调用栈，就会抛出 RecursionError: maximum recursion depth exceeded。
关键点在于：CPython 不做尾调用优化，哪怕你写成尾递归形式（如 def f(n, acc): return f(n-1, acc+n)），每层调用仍压入新栈帧，和普通递归一样危险。
- 不是“递归写错了”，而是“递归本身不适合深链式数据遍历”
- 数据库查出的嵌套层级可能远超预期（比如用户意外构造了 2000 层的评论回复链）
- 错误往往只在特定数据下暴露，本地测试容易漏掉
用显式栈替代隐式递归（推荐首选）
把递归逻辑手动转成 while 循环 + 列表/队列存待处理节点，完全避开调用栈限制。适合树、图、关系链等结构。
例如，把递归获取部门上级链改成迭代：
# 原递归写法（危险）
def get_ancestors_recursive(dept):
if not dept.parent:
return []
return [dept.parent] + get_ancestors_recursive(dept.parent)
<h1>迭代写法（安全）</h1><p>def get_ancestors_iterative(dept):
ancestors = []
current = dept.parent
while current:
ancestors.append(current)
current = current.parent
return ancestors
</p>
- 不依赖函数调用深度，只消耗堆内存，可控性强
- 可加深度限制：在
while循环里计数，超过阈值直接 break 或报错 - ORM 场景下，配合
select_related或prefetch_related一次查出多层关联，避免 N+1 查询
@lru_cache 只对重复子问题有效，不解决深度问题
@lru_cache 能大幅减少调用次数（比如斐波那契从 O(2ⁿ) 降到 O(n)），但它不改变单次调用的最大深度。如果原始递归链就是 1500 层，缓存再好也照样 RecursionError。
- 适用场景：输入参数组合有限、存在大量重复子调用（如动态规划类计算）
- 不适用场景：链式结构遍历、每次参数都不同（如
get_parent_of(parent_of(parent_of(...)))） - 注意：
@lru_cache要求参数可哈希，模型实例默认不可哈希，得用 ID 替代对象传参
生成器 yield from 不能绕过栈深度限制
网上有方案用 yield + 递归生成器假装“尾递归优化”，但这是误导。Python 解释器并不因此复用栈帧；yield 只是暂停执行并返回生成器对象，递归调用本身仍在栈上累积。实测 fib(2000) 依然会崩。
- 真正有效的生成器用法是“分批产出”，比如
yield from flatten(child)替代return flatten(child) + flatten(other)，避免拼接大列表和长调用链 - 但若底层仍是深度递归调用，生成器只是延迟崩溃，不是根治
- 对 Web 请求，更稳妥的是前端分页 + 后端按层级懒加载，而非一次性拉全树
最易被忽略的一点：递归查询常和 ORM 的懒加载（lazy loading）耦合，表面看是代码递归，实际是每次访问属性都触发一次 SQL 查询 + Python 层递归展开。先关掉自动关联加载，再用 select_related 控制层数，比硬刚递归更治本。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
