asyncio.Event是最轻量的多协程同步唤醒机制，适合“一信号多等待”场景，但不传数据、不保序、不自动清除；event.set()是同步方法，不可await，需在协程中直接调用，配合event.wait()使用，并注意唤醒丢失与取消安全。
asyncio.Event 是最轻量、最直接的多协程同步唤醒机制，适合“一个信号触发多个等待者”的场景；但它不传递数据、不保证唤醒顺序、也不支持重置后自动清除状态——用错地方反而会卡死。
为什么不能直接 await event.set()？
event.set() 是同步方法，返回 None，不能 await。常见错误是写成 await event.set()，结果报 TypeError: object NoneType can't be used in 'await' expression。
正确做法是：在某个协程中调用 event.set()（不加 await），其他协程用 await event.wait() 阻塞等待。
-
event.set()立即生效，所有已进入wait()的协程会被唤醒 - 如果事件已被 set 过，后续
await event.wait()会立刻返回（无需再clear()） - 若需重复使用，必须手动调用
event.clear()，否则所有新来的wait()都不会阻塞
如何避免“唤醒丢失”？
典型问题：生产者协程先 event.set()，消费者协程后 await event.wait()，结果消费者永远等不到——因为事件状态已是 True，wait() 直接返回，但业务逻辑还没准备好。
立即学习“Python免费学习笔记（深入）”；
根本原因：Event 只表示“是否被设过”，不记录“谁该响应”。解决思路是配合状态变量或二次检查：
- 用一个共享的
flag: bool或data: Optional[Any]变量，set()前先更新它 - 消费者
await event.wait()后，立刻检查该变量是否就绪，未就绪则event.clear()并重试 - 更稳妥的做法是把
event和数据封装进一个类，统一管理 set/clear/notify 流程
asyncio.Event 在取消（Cancellation）下怎么安全使用？
协程被 asyncio.CancelledError 中断时，若正卡在 await event.wait()，它会正常抛出异常并退出——这点比 asyncio.Condition 更干净。
但要注意：如果 event.set() 正在执行过程中协程被取消，不会影响事件状态；而如果多个协程同时 set()，也完全安全（内部用 threading.Event 语义，线程/协程安全）。
- 不需要在
try/finally里clear()，除非你明确要重用这个 Event - 若想确保某次唤醒只服务一次，必须手动
event.clear()，且最好放在消费者处理完逻辑之后 - 不要在
set()后立刻clear()——这会导致刚唤醒的协程又陷入等待
真正容易被忽略的是：Event 没有“超时唤醒后自动 clear”的能力，也没有“只唤醒一个”的变体。需要这些行为时，别硬套 Event，该换 asyncio.Queue 或 asyncio.Semaphore 就换。
