asyncio.Condition()必须显式传入asyncio.Lock实例，否则报错；wait()需在持锁时调用，会自动释放并重获锁；notify无需持锁但建议在锁内调用以保证原子性；不可用threading.Condition替代，因其阻塞事件循环。
Condition对象在asyncio中怎么初始化
直接用 asyncio.Condition()，但必须传入一个已存在的 asyncio.Lock 实例——这是最容易漏掉的一步。不传锁会报 TypeError: condition must be initialized with a lock，而很多人误以为它能自动创建内部锁。
正确写法是先创建锁，再传给 Condition：
lock = asyncio.Lock() cond = asyncio.Condition(lock)
虽然你也可以省略显式传入（asyncio.Condition() 内部会新建一个 Lock），但显式传入更安全：能复用已有锁、便于调试、避免意外的锁粒度问题。
wait() 和 notify() 的协程语义和调用约束
await cond.wait() 会原子性地释放关联锁、挂起当前协程，并在被唤醒后重新获取锁——注意，它**不是**简单“等通知”，而是“释放锁 → 等 → 重拿锁”的三步组合。这意味着：
- 调用
wait()前，当前协程**必须已持有**该 Condition 关联的锁（否则抛RuntimeError: await wait() only allowed inside a locked context） -
notify()或notify_all()不需要持锁也能调用，但通常应在持有锁的上下文中调用，以保证状态检查与通知的原子性 - 被
wait()唤醒的协程，恢复执行时**一定已重新拿到锁**，可立即读取共享状态
典型模式是：“加锁 → 检查条件是否满足 → 不满足则 await wait() → 满足则处理”。别跳过检查，否则可能错过通知或陷入虚假唤醒。
为什么不能用 threading.Condition 替代 asyncio.Condition
直接拿 threading.Condition 在 async 函数里用，会阻塞整个事件循环。比如：
import threading cond = threading.Condition() ... await cond.wait() # ❌ RuntimeError: cannot reuse already awaited coroutine
这是因为 threading.Condition.wait() 是同步阻塞调用，返回的是普通布尔值，不是协程对象；而 await 只接受协程。更严重的是，它会让当前线程卡住，导致其他协程无法调度。
asyncio 的 Condition 是纯协程友好实现，所有方法（wait、notify、notify_all）都返回协程对象，且内部不涉及任何线程阻塞操作。
实际场景：生产者-消费者模型中用 Condition 控制缓冲区满/空
当缓冲区容量有限，需同时等待“有空位”（生产者）和“有数据”（消费者）时，Condition 比单纯用 asyncio.Queue 更灵活——比如你想支持超时等待、批量通知、或结合复杂业务逻辑判断唤醒条件。
关键点：
- 用一个共享变量（如
buffer列表） + 一个asyncio.Condition实例 - 生产者加锁后检查
len(buffer) ，不满足就await cond.wait() - 消费者加锁后检查
len(buffer) > 0，不满足也await cond.wait() - 任一端修改缓冲区后，调用
cond.notify_all()（或notify()）唤醒等待者
注意：两次检查必须在同一个锁保护下完成，否则竞态条件会导致死锁或数据错乱。
Condition 的核心难点不在 API，而在状态检查与通知的配对逻辑——漏检、重复通知、错用锁作用域，都会让协程永远挂起。写完务必用多个并发生产/消费任务压测，观察是否出现卡死或丢失信号。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
