asyncio.Event是协程安全的布尔标志，仅含“已设置/未设置”状态，需配对使用set()和clear()实现单次通知；误用易致虚假唤醒，复杂场景推荐asyncio.Queue。

asyncio.Event 本质是协程安全的布尔标志

asyncio.Event 不是信号量（asyncio.Semaphore），它没有计数能力，只提供「已设置 / 未设置」两种状态。它的核心价值在于：让一个协程能 等待 另一个协程调用 set()，且整个过程不阻塞事件循环。常见误用是拿它当「发一次、收多次」的广播工具——但默认情况下，wait() 被唤醒后状态仍保持 True，后续 wait() 会立刻返回，除非手动 clear()。

跨协程通知必须配对使用 set() 和 clear()

若想实现「通知一次、只被消费一次」的效果（比如模拟信号量的 acquire/release 行为），必须显式管理状态生命周期：

• 发送方调用 event.set() 后，通常应尽快调用 event.clear()，否则下次 wait() 不会挂起
• 接收方在 await event.wait() 返回后，应主动检查业务条件是否真正满足（避免虚假

  

  唤醒），再决定是否继续执行
• 多个协程同时 await event.wait() 会全部被唤醒，但只有第一个可能拿到资源——需配合锁或队列做二次协调

替代方案：用 asyncio.Queue 实现带缓冲的通知

如果需要「多生产、单消费」或「保留通知历史」，asyncio.Event 就力不从心了。更稳妥的选择是 asyncio.Queue：

q = asyncio.Queue(maxsize=1)
# 发送通知（非阻塞，丢弃旧通知）
try:
    q.put_nowait("signal")
except asyncio.QueueFull:
    q.get_nowait()  # 清掉旧的
    q.put_nowait("signal")
接收方
msg = await q.get()  # 真正阻塞等待

asyncio.Queue 天然支持跨协程、线程安全、可设容量，比手动维护 Event 状态更少出错。

容易忽略的陷阱：loop 不一致与 await 时机

两个常见崩溃点：

• asyncio.Event 必须在同一个事件循环中创建和使用；跨线程或跨 loop 创建会导致 RuntimeError: a task is already running
• 在 await event.wait() 前，确保 event.set() 不会在当前协程刚挂起时就被调用——否则可能错过通知。保险做法是先 set() 再 await wait()，或用 asyncio.create_task() 确保调度顺序

复杂场景下，别硬套 Event；通知语义越模糊，越该换 Queue 或 Condition。