asyncio.Condition 专为多协程按条件排队、分批唤醒设计；必须用 while 循环检查条件，因 wait() 不保证唤醒时条件成立；状态需手动维护且所有读写须在锁保护下进行；notify() 和 notify_all() 差异在于是否允许竞争下状态覆盖；notify 前必须已持有锁，推荐用 async with condition: 修改状态并 notify。
asyncio.Condition 不是给单次等待/通知用的，它本质是为「多个协程按条件排队、分批唤醒」设计的——如果你只是想等一个事件，用 asyncio.Event 更安全；真要用 Condition，必须配合显式的条件检查和循环等待，否则极易漏唤醒或死锁。
为什么 await condition.wait() 后必须重新检查条件？
因为 wait() 只是释放锁并挂起，不保证唤醒时条件已满足。其他协程可能在你等待期间修改了共享状态，也可能发生虚假唤醒（尤其在某些系统底层实现中）。
- 正确模式是：用
while not some_condition:包裹await condition.wait() - 条件变量本身不存储状态，它只协调访问——状态得你自己维护（比如用一个
list或int） - 所有读写该状态的地方，都必须在
condition的锁保护下进行（即调用acquire()后操作）
notify() 和 notify_all() 的实际差异在哪？
区别不在“通知多少个”，而在于「是否允许竞争条件下的状态覆盖」。
-
notify(1)只唤醒一个在wait()中阻塞的协程，其余继续等——适合「生产者-消费者」中每次只处理一个任务的场景 -
notify_all()唤醒全部等待者，但它们会重新竞争锁，再各自检查条件——适合「广播式通知」，比如配置重载后所有监听者都要重新校验自身状态 - 注意：
notify()不保证唤醒的是「最久等待」的那个，也没有优先级概念
典型错误：忘记在 notify 前 acquire 锁
Condition.notify() 要求调用前已持有其关联锁，否则抛 RuntimeError: acquire must be held。很多人以为只要 await condition.wait() 过就“有锁感”了，其实 wait() 会自动释放锁，唤醒后也不会自动重拿。
立即学习“Python免费学习笔记（深入）”；
- 正确顺序：
await condition.acquire()→ 修改状态 →condition.notify()→condition.release() - 更稳妥写法是用异步上下文管理器：
async with condition: # 修改共享状态 condition.notify() - 漏掉
release()会导致后续所有协程卡在acquire()，且不会报错，只表现为死锁
真正难的不是写对语法，而是把「谁改状态」「谁读状态」「谁决定通知谁」这三件事，在并发逻辑里拆清楚。一个 Condition 实例背后，至少要明确两个角色：状态变更方（负责 notify）和等待方（负责循环 wait），中间不能混进第三方随意读写。否则调试时你会发现协程醒了却没干活，或者一直不醒——问题八成出在条件判断逻辑没和 notify 动作严格对齐。
