Python异步代码如何实现递归调用_协程嵌套深度与性能优化技巧-Python教程-PHP中文网

不会立即报RecursionError，因协程非可调用对象，错误写法会导致RuntimeError或栈/内存耗尽；瓶颈在IO调度与内存管理，优化关键为控制并发数、使用Semaphore和create_task，深度递归应重构为状态机。

python异步代码如何实现递归调用_协程嵌套深度与性能优化技巧

async def 里直接 await 自己会报 RecursionError 吗？

不会立即报 RecursionError，但会快速耗尽事件循环栈或引发 RuntimeError: coroutine object is not awaited —— 因为 Python 的协程对象不是可调用对象，不能像普通函数那样“直接递归调用”。常见错误写法是：

await

用 async for 或队列 + asyncio.Queue 将递归转为广度优先的协程池调度

对深度可控的场景（如最多 5 层嵌套），直接 await 调用自身，但加深度参数限制：

async def fetch_with_depth(url, depth=0, max_depth=3):
    if depth >= max_depth:
        return []
    data = await http_get(url)
    children = parse_links(data)
    return await asyncio.gather(
        *(fetch_with_depth(u, depth + 1, max_depth) for u in children)
    )

避免在 asyncio.run() 内启动高深度递归 —— 它每次调用都会新建事件循环，开销大且不支持跨循环 await

协程嵌套太深会卡死或变慢？和 event loop 有关吗？

卡死通常不是因为“嵌套深”，而是因为：

大量协程同时 await 同一个慢 IO（如没限速的并发 HTTP 请求），触发连接池耗尽或服务端限流，整体阻塞
递归生成的协程对象过多，但未及时 await 或 asyncio.gather 调度，导致内存堆积（每个 coroutine 对象约 200–300 字节）
在非 async 函数里错误使用 asyncio.get_event_loop().run_until_complete() 嵌套调用，引发运行时异常

Python 的 event loop 本身不设协程调用栈深度限制，但 CPython 解释器对 Python 栈帧有默认限制（sys.getrecursionlimit()），而协程切换不走 C 栈，所以纯 async/await 不触发该限制 —— 真正瓶颈常在 IO 调度策略或内存管理。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

性能优化的关键其实是控制并发数，不是减少 await 层数

实测表明：把 1000 个 await fetch() 直接展开，比用 5 层嵌套 + 每层 asyncio.gather(..., return_exceptions=True) 慢 3–5 倍，原因在于调度器要维护更多待决协程状态。优化要点很实在：

用 asyncio.Semaphore 限制并发请求数，例如 sem = asyncio.Semaphore(10)，每个协程先 async with sem: 再发请求
对可并行子任务，用 asyncio.create_task() 显式提交，比直接 await 递归更利于调度器批处理
避免在循环内反复创建新 event loop（如在普通函数里调用 asyncio.new_event_loop()），应复用或通过 asyncio.run() 统一入口
深度大于 8 的异步递归基本该重构为状态机或任务队列 —— 不是因为语法不支持，而是调试困难、超时难控制、取消逻辑易漏