为何Python中await的对象需实现返回迭代器的__await__()方法？

先看你给出的自定义可等待对象示例：

class Meet:
    def __await__(self):
        yield "Hello"
        return "World"

meet = Meet()

针对你提出的疑问，下面逐一拆解：

为什么await要求对象实现返回迭代器的__await__()？ #

要搞懂这个问题，得从Python协程的底层根源讲起——asyncio的前身是基于生成器（generator）实现的协程机制，async/await语法其实是对生成器协程的语法糖封装。

生成器本身就是天然的可暂停、可恢复的执行单元，通过yield可以把控制权交出去，后续再通过send()唤醒继续执行。而__await__返回迭代器，本质就是复用这套成熟的暂停-恢复逻辑，把自定义可等待对象的等待过程，转化为事件循环能识别的调度单元。

简单说，要求返回迭代器的核心逻辑是：给事件循环提供统一的“暂停-唤醒”接口，让所有可等待对象的等待行为都能被事件循环标准化调度，不用为每种对象单独写适配逻辑。

await迭代该迭代器时底层发生了什么？ #

当你执行await meet时，Python会先调用meet.__await__()拿到迭代器，然后交给事件循环处理：

• 事件循环第一次调用next(iterator)，代码执行到yield "Hello"，当前协程被暂停，控制权回到事件循环；
• 事件循环会根据yield出来的值（实际场景里可能是IO句柄、Future对象这类需要等待的资源），去处理对应的等待逻辑——比如监听IO完成的信号；
• 当等待的条件满足（比如IO操作完成），事件循环会调用iterator.send(None)，让协程从yield的位置恢复执行；
• 迭代器继续执行到return "World"，这时会抛出StopIteration("World")异常，await会捕获这个异常，并把异常的value属性作为await的返回值（也就是result = await meet会得到"World"）。

能否设计为支持任意对象而非必须返回迭代器？ #

理论上可以，但这样做会丢掉现有设计的两个关键优势：

• 复用成熟的生成器机制：生成器的迭代器模型已经经过多年验证，能稳定处理暂停/恢复、异常传递、上下文保存这些复杂逻辑，重新造一套新的调度模型会大幅增加语言的复杂度和维护成本；
• 统一的接口标准：要求返回迭代器相当于给所有可等待对象定了一个统一协议，事件循环只需要处理迭代器的next()/send()操作，就能兼容所有自定义可等待对象，开发者也不用额外实现复杂的调度适配逻辑。

如果改成支持任意对象，事件循环就得判断每个对象的类型，为不同对象写不同的等待逻辑，这会让asyncio的核心代码变得臃肿，也会让自定义可等待对象的门槛变高——你得自己告诉事件循环怎么等待这个对象，而不是复用现成的迭代器机制。

内容的提问来源于stack exchange，提问作者Meet Patel