asyncio.condition 必须显式绑定 asyncio.lock，因它仅负责协程挂起/唤醒而不管理临界区；wait() 前须已持锁，且需 while 循环防虚假唤醒；notify() 唤醒不可靠，不应依赖顺序或即时性。
asyncio.Condition 不是协程版的“锁+事件”简单叠加，它必须和 asyncio.Lock 绑定使用，否则 RuntimeError: Condition requires a Lock 会立刻报错。
为什么必须显式传入 Lock？
asyncio.Condition 本身不管理临界区，它只负责挂起/唤醒协程；真正的互斥保护由外部传入的 asyncio.Lock 承担。这和 threading.Condition 的设计一致，但 Python 新手常误以为它自带锁。
- 必须显式创建并传入：
cond = asyncio.Condition(lock=asyncio.Lock()) - 不能复用其他协程正在使用的锁（比如多个
Condition共享一个锁时，notify_all()会唤醒所有等待者，可能引发逻辑混乱） - 若用
async with cond:，实际是进入其绑定的锁的上下文，不是进入 condition 本身
wait() 前必须先 acquire 锁，且 wait() 会自动释放再重获
这是最易出错的环节：忘记在 wait() 前加 await lock.acquire() 或误用 async with 嵌套顺序，会导致 RuntimeError: cannot wait on un-acquired lock。
Python Sdk
下载
inference.sh 的 Python SDK：运行 AI 应用、构建智能体，并集成 150 多个模型。包名：inferencesh (pip install inferencesh)。支持同步/异步……
- 正确模式：
async with cond: while not some_condition: await cond.wait() - 错误写法：
await cond.wait()单独调用（没进async with cond或没手动 acquire） -
wait()内部会先释放锁，挂起当前协程；被notify()唤醒后，会重新竞争并获取锁，再返回 —— 所以while循环检查条件必不可少，防止虚假唤醒
notify() 和 notify_all() 的唤醒时机不可靠
notify(n) 只保证「至少唤醒 n 个正在 wait() 的协程」，但不保证它们立即执行，也不保证唤醒的是你预期的那个。尤其在高并发或任务调度压力大时，唤醒顺序与注册顺序无关。
- 不要依赖唤醒顺序做状态流转（比如“第一个被唤醒的协程负责初始化，第二个负责消费”）
- 避免在
notify()后立刻假设某协程已修改共享状态 —— 应始终用while检查条件变量的实际值 - 如果需要精确控制唤醒目标，应改用多个专用
asyncio.Event或带标识的队列，而非强求Condition
真正难的不是写对语法，而是把「谁在等什么条件」「谁负责更新条件」「通知是否遗漏或重复」这三件事，在协程生命周期里理清楚。一旦状态判断逻辑分散在多个 wait() 循环外，Condition 就会变成隐藏的竞态源头。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
