异步死锁是协程await永久不释放的锁时静默挂起，主因是多协程交叉获取锁顺序不一致导致循环等待；须按全局统一顺序加锁、缩小临界区、禁用手动acquire/release、用async with确保释放。
异步死锁不是“卡住”，而是协程在 await 一个永远不被释放的锁或资源时，安静地挂起——没有报错、没有日志、只有请求无声超时。
为什么 await 顺序错乱会直接引发死锁
多个协程交叉请求多个 asyncio.Lock 时，若获取顺序不一致，极易形成循环等待。比如协程 A 先 await lock_a.acquire() 再 await lock_b.acquire()，而协程 B 反过来先 await lock_b.acquire() 再 await lock_a.acquire()。一旦两者分别拿到第一个锁，就会互相等待对方释放第二个锁。
这种死锁无法靠超时自动解除，因为 acquire() 本身不带内置超时（除非显式传 timeout=）。
- 始终按**全局统一顺序**获取锁：例如按锁变量名字母序（
lock_cache→lock_db）、或按资源重要性（配置锁 → 缓存锁 → 数据库锁） - 避免在
async with lock:块内再await另一个锁的acquire()—— 这是嵌套锁风险高发区 - 如必须多锁协作，用
asyncio.wait_for(lock.acquire(), timeout=2)强制设限，捕获asyncio.TimeoutError后主动释放已持锁并重试
锁粒度太粗导致事务/IO阻塞时间过长
把整个 HTTP 请求处理逻辑包进一个 async with big_lock:，等同于把并发能力降为 1。更危险的是，若其中包含数据库查询、外部 API 调用或 asyncio.sleep()，锁会长时间空转占用，其他协程持续排队，最终堆积超时。
立即学习“Python免费学习笔记（深入）”；
- 只包裹真正需要互斥的**最小临界区**：例如仅对共享计数器增减、缓存键写入、文件头写操作等几行代码加锁
- 把耗时 IO（DB 查询、HTTP 调用）移出
async with块，提前完成或延后执行 - 考虑用
asyncio.Semaphore(1)替代Lock—— 语义更明确，且便于后续扩展为允许多个并发（如Semaphore(5)）
忘记释放锁或异常中断导致锁泄露
asyncio.Lock 不是线程锁，它不支持跨协程释放；一旦某个协程在持有锁时未正常退出（如抛出未捕获异常、return 早于 release()），该锁将永久处于 acquired 状态，所有后续协程都会无限等待。
- 绝对不要手动调用
lock.acquire()+lock.release()—— 必须用async with lock:保证自动释放 - 若需在异常路径中做清理，把清理逻辑放在
async with块内，而非之后：因为async with的__aexit__一定触发，但块外代码可能根本执行不到 - 可在锁创建时加标识（如
lock = asyncio.Lock(); lock._name = "user_balance_update"），配合日志观察谁长期持有锁（需自行 patch 或用调试工具）
最易被忽略的一点：异步锁的「持有者」是协程，不是线程，也不是事件循环。一个协程挂起后，锁不会自动转移或超时释放——它就停在那里，静默地扼杀所有后续请求。所以，async with 不是语法糖，是安全底线；统一锁序不是教条，是避免循环等待的唯一可靠手段。
