asyncio.run() 嵌套调用会死锁，因python禁止在运行事件循环中启动新循环；正确做法是顶层用asyncio.run()，内部用await；lock必须用async with确保自动释放；跨线程调用需用run_coroutine_threadsafe并校验loop状态。
asyncio.run() 里嵌套另一个 asyncio.run() 会直接死锁
这是最典型的死锁诱因：Python 不允许在已运行的事件循环中再次调用 asyncio.run()。它内部会尝试启动新事件循环，但当前线程已有运行中的循环，导致阻塞等待自己结束——永远等不到。
常见于单元测试或脚本中误写：
import asyncio <p>async def inner(): await asyncio.sleep(0.1) return "done"</p><p>def bad_wrapper():</p><h1>❌ 错误：在同步函数里又调用 asyncio.run()</h1><pre class="brush:python;toolbar:false;">return asyncio.run(inner()) # 这里卡住
async def good_wrapper():
✅ 正确：await 协程对象
return await inner()
调用方式也需匹配
asyncio.run(good_wrapper()) # OK
asyncio.run(bad_wrapper()) # ❌ 死锁
- 只要看到
RuntimeError: asyncio.run() cannot be called from a running event loop，基本就是这个原因 - 所有被
async修饰的函数必须用await调用，不能用asyncio.run() -
asyncio.run()只应作为程序入口（顶层同步代码）使用一次
await asyncio.Lock() 后忘记 release() 或未用 async with
asyncio.Lock 是协程安全的，但它的使用规则和线程锁不同：它不支持手动 release() 后再 acquire()，更不能跨 await 点释放——一旦 await 导致协程让出控制权，而锁没释放，其他协程就会永久等待。
正确写法只有一种推荐路径：
lock = asyncio.Lock() <p>async def critical_section(): async with lock: # ✅ 自动 acquire + release，即使异常也安全 await asyncio.sleep(1) return "processed"</p>
- 不要写
await lock.acquire()+ 手动lock.release()，容易遗漏或提前释放 - 尤其注意：
lock.release()在未持有锁时调用会抛RuntimeError: release unlocked lock，但死锁往往发生在“一直不 release” - 如果需要超时控制，用
async with asyncio.timeout(2):包裹async with lock:
sync function 中调用 asyncio.get_event_loop().run_until_complete()
在非主线程、或已关闭的事件循环上下文中调用 run_until_complete()，常表现为卡死无报错。典型场景是多线程 Web 框架（如 Flask）里试图从请求处理函数中驱动协程。
例如：
from flask import Flask
import asyncio
<p>app = Flask(<strong>name</strong>)
loop = asyncio.new_event_loop() # ❌ 错误：在非主线程/非标准上下文新建 loop</p><p>@app.route("/api")
def handler():</p><h1>这里可能运行在任意线程，loop 可能未启动或已关闭</h1><pre class="brush:python;toolbar:false;">return loop.run_until_complete(some_async_func()) # ⚠️ 极易死锁
- 永远优先用
async def handler()配合支持异步的框架（如 FastAPI、Starlette） - 若必须桥接同步环境，用
asyncio.run_coroutine_threadsafe(coro, loop)并确保loop是运行中的（且在同一线程创建/启动） - 检查
loop.is_running()和loop.is_closed()再操作，否则静默卡住
await 一个永远不会 resolve 的 Future 或 Task
协程挂起在某个 await 表达式上，而该表达式背后没有实际完成机制，就等于主动给自己加了无限等待。常见于：
- 手动创建
asyncio.Future()但忘了set_result()或set_exception() - 等待一个已 cancel 但未 await 的
Task（cancel 不等于完成） - 使用
asyncio.wait_for()但超时时间设为None，且目标协程本身有逻辑缺陷无法退出
排查建议：
# 查看当前所有 pending task（调试时插入）
for task in asyncio.all_tasks():
print(task.get_coro(), task.done(), task.cancelled())
重点关注状态为 pending 且长时间不变的任务，顺藤摸瓜看它 await 了什么。
死锁真正麻烦的地方不在现象，而在它不报错、不中断、只沉默——你得主动去问事件循环“现在谁卡着”，而不是等它开口告诉你。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
