notify_all() 不保证所有等待协程立即执行，因唤醒后需重新竞争锁并检查条件；必须遵循“改状态→通知”顺序，且wait()须置于while循环中。
asyncio.Condition() 的 notify_all() 不唤醒所有等待协程？
这是最常见的误解：调用 notify_all() 后，部分协程仍卡在 wait()，不是 bug，而是因为条件变量本身不检查条件是否真的满足——它只负责“发信号”，后续必须由协程自己重新判断条件。
典型错误是写成这样：
async with cond:
cond.notify_all() # ✅ 发了信号
# ❌ 但没改共享状态，等的人醒来后 check 条件仍是 False，立刻又 await wait()正确做法永远遵循「修改状态 → 通知」顺序，且通知后不假设条件已成立：
- 共享状态（如
data_ready）必须是协程间可见的变量（例如类属性、全局变量或传入的可变对象） -
notify_all()前必须已更新该状态，否则唤醒纯属浪费 - 每个
wait()调用都应包裹在while not condition:循环里，不能用if
多个协程 await wait() 时，谁先被唤醒？
Python 3.11+ 的 asyncio.Condition 使用 FIFO 队列管理等待者，notify_all() 按等待顺序依次唤醒；但注意：唤醒 ≠ 立即执行 —— 被唤醒协程要等当前持有锁的协程退出 async with 块后，才能重新竞争锁并检查条件。
立即学习“Python免费学习笔记（深入）”；
这意味着：
- 如果通知者长时间持有锁（比如在
async with cond:里做耗时 IO），后续协程会排队阻塞，看似“没响应” - 不要依赖唤醒顺序做业务逻辑（比如“第一个醒的负责写文件”），因为调度受事件循环和锁争抢影响
- 若需严格顺序控制，应额外加序号标记或用队列协调，别指望
Condition保证
await cond.wait() 为什么有时直接返回，不挂起？
这不是异常，而是设计行为：wait() 在进入等待前会**自动释放锁**，并在被唤醒后**自动重新获取锁**；但如果在释放锁到真正挂起之间，另一个协程快速完成修改 + notify，当前协程可能“错过”通知，但此时它还没开始等，所以不会挂起，直接向下执行。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
这恰恰是为何必须用 while 循环检查条件：
async with cond:
while not data_available: # ✅ 必须循环
await cond.wait() # ❌ 单次 if 会导致跳过检查常见诱因：
- 条件变量和共享状态不在同一把锁下保护（比如状态用
threading.Lock，而cond是asyncio的）→ 完全不同步 - 多个
Condition实例误用于同一状态 → 通知发错对象 - 忘记在
async with cond:内部修改状态，导致状态变更未被锁保护
asyncio.Condition 和 asyncio.Event 哪个更适合“一次通知，多人响应”？
看场景：asyncio.Event 更轻量、语义更清晰——它天生就是“信号灯”，set() 后所有 wait() 都立即返回，且不会自动重置；而 Condition 天然绑定锁、支持复杂条件判断，但多一层抽象，容易用错。
选 Event 当：
- 只关心“某事发生了”，不依赖其他状态（比如“配置加载完成”）
- 不需要在等待时做额外锁保护操作
- 希望通知后所有协程无条件继续，不检查任何前置条件
选 Condition 当：
- 需要配合共享数据（如缓冲区非空、计数器 > 0）
- 等待逻辑本身要加锁（比如读写队列时防止竞态）
- 需要
notify()只唤醒一个，或动态决定唤醒数量
混用风险高：用 Event 做状态同步，却用 Condition 做锁保护，结果状态变更没被锁住，协程看到的就是脏值。
