asyncio.Condition 不能直接 await，因其本身非协程，仅 wait()、notify() 等方法是可等待对象；必须通过 asyncio.Condition(lock) 实例化并配合状态变量与 async with 语句使用。
asyncio.Condition 为什么不能直接 await
因为 asyncio.Condition 本身不是协程，它的核心方法（如 wait()、notify()）才是可等待对象。常见错误是写成 await cond 或漏掉括号调用 cond.wait（没加 ()），结果报 TypeError: object Condition can't be used in 'await' expression 或静默卡死。
必须确保：
– 条件对象由 asyncio.Condition() 实例化（且通常需传入共享的 Lock）；
– 所有对 wait()、notify()、notify_all() 的调用都带括号并用 await；
– wait() 只能在已获取锁的上下文中调用（即必须在 async with cond: 块内）。
生产者如何安全地 notify 而不丢失信号
典型陷阱：生产者调用 cond.notify() 时，消费者还没执行到 wait()，导致唤醒丢失。这不是 bug，而是条件变量的设计特性——它不缓存通知。
解决方式是配合状态变量（如队列长度、标志位）使用：
立即学习“Python免费学习笔记（深入）”；
- 用一个
asyncio.Queue或普通列表 +asyncio.Lock存数据，把“是否有数据可消费”这个事实显式维护起来 - 消费者在
async with cond:块中，先检查状态（例如if not items:），再调用await cond.wait() - 生产者在追加数据后调用
cond.notify()，但不保证立刻被响应——靠循环检查+等待实现“等待直到满足条件”
示例关键片段：
async def consumer(cond, items):
async with cond:
while not items: # 状态检查
await cond.wait() # 等待通知
item = items.pop(0)
return item
<p>async def producer(cond, items):
async with cond:
items.append("data")
cond.notify() # 不用 await
notify() 和 notify_all() 在多消费者场景下怎么选
如果多个消费者都在等同一个条件（比如共用一个缓冲区），用 notify() 只会唤醒一个，其余继续挂起；用 notify_all() 会唤醒全部，但它们会竞争锁和数据——可能只有一个能成功消费，其余又得重新判断状态、再次等待。
选择依据：
- 单个任务处理即可（如日志写入、事件广播）→ 用
notify()更轻量 - 需要所有等待者都响应变化（如配置重载、全局开关切换）→ 用
notify_all() - 缓冲区允许多个并发消费（如 worker pool）→ 仍推荐
notify()，避免惊群；配合 while 循环检查状态，让“抢到锁”的协程决定是否真干活
注意：notify_all() 不保证唤醒顺序，也不保证全部立即执行——它们仍要排队获取锁。
别忘了 lock 参数，否则 condition 毫无意义
asyncio.Condition 必须绑定一个锁（默认创建 asyncio.Lock()），否则 async with cond: 会失败。更隐蔽的问题是：如果多个 condition 共享同一个底层锁，或误用不同锁，会导致死锁或状态不一致。
正确做法：
- 显式传入锁：
lock = asyncio.Lock(); cond = asyncio.Condition(lock) - 确保所有协程（生产/消费）都用同一个
cond实例（即同一个锁） - 不要混用
threading.Condition和asyncio.Condition—— 后者只用于协程环境，前者会阻塞整个 event loop
最容易被忽略的一点：condition 的等待逻辑依赖锁的释放与重入，若在 async with cond: 外修改共享状态（比如往 items 列表 append），就破坏了原子性，可能导致消费者看到中间态。
