asyncio中不存在因await导致的栈溢出，真正栈溢出只来自同步递归函数；await会清空调用栈，协程恢复时使用新栈帧；风险在于资源耗尽或无限await循环，而非recursionerror。
asyncio 里根本不存在“递归调用导致的栈溢出”——await 不会增加 Python 的调用栈深度，真正的栈溢出只可能来自同步递归函数内部，而非 await 链本身。
async/await 本身不增加递归深度
每次 await 表达式执行时，当前协程挂起、控制权交还事件循环，函数帧退出，栈被清空。下一次恢复执行时是全新帧。所以写成这样完全安全：
async def fetch_recursive(url, depth=0):
if depth >= 5:
return []
resp = await httpx.get(url)
return [resp] + await fetch_recursive(resp.json().get("next_url"), depth + 1)
上面代码不会触发 RecursionError，但可能因逻辑错误陷入无限 await（比如 next_url 总是返回非空），最终耗尽内存或超时，而不是爆栈。
- 真正爆栈的是你在
await里调用了同步递归函数（比如在回调中调用factorial(n)） -
async def函数体内的同步代码仍受sys.getrecursionlimit()约束 - 协程调度器不管理 Python 调用栈，它只管理任务队列和事件循环
常见误踩坑：在 async 函数里嵌套同步递归
典型错误场景：ORM 查询 + 递归解析嵌套关系，比如：
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
async def get_full_tree(node):
children = await Node.objects.filter(parent=node).all() # OK
result = [node]
for child in children:
result.extend(get_full_tree_sync(child)) # ❌ 这里才是爆栈源头！
return result
问题出在 get_full_tree_sync() 是纯同步递归函数，跟 asyncio 无关。解决方式不是改 await，而是：
- 把
get_full_tree_sync改成迭代写法（用deque或list模拟栈） - 如果必须保留递归逻辑，加深度计数并提前
raise ValueError("too deep") - 避免在异步函数中混用深层同步递归——先想清楚：这部分真需要递归吗？
真正要防的是“伪递归”+无限 await 循环
看起来像递归，实则是事件循环里不断新建协程，容易耗尽内存或触发连接限制：
- 没设终止条件的
await fetch_recursive(url)可能拉取几千层 URL，生成上万个Task对象 - 没做节流的重试逻辑（如指数退避漏了
await asyncio.sleep()）会压垮事件循环 - ORM 中
select_related深度过大 +await嵌套，虽不爆栈，但可能拖慢整个循环
正确做法是显式控制链长：
async def fetch_with_depth_limit(url, max_depth=10):
stack = [(url, 0)]
results = []
while stack:
u, d = stack.pop()
if d >= max_depth:
continue
resp = await httpx.get(u)
results.append(resp)
next_url = resp.json().get("next")
if next_url:
stack.append((next_url, d + 1))
return results
关键点始终是：爆栈永远发生在同步调用栈里；asyncio 的风险是资源耗尽、响应延迟或死循环，不是 RecursionError。别被“递归式 await”表象骗了，先检查函数体内有没有隐藏的同步递归调用。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
