Python asyncio eager task factory 什么时候会改变执行顺序

直接答案：asyncio.eager_task_factory 会在代码依赖“create_task() 返回后，协程才开始执行”这一边界时改变顺序。启用后，协程会在 Task 构造期间立即运行，直到遇到第一个真正阻塞的 await。如果它同步返回或抛错，甚至不会进入事件循环队列。

变化发生在 create_task 调用内部

默认任务工厂先创建并调度 Task，调用方继续向下执行，协程函数体等事件循环取得控制权后才开始。eager 工厂把“开始执行”提前到 Task 构造阶段，因此首个阻塞点之前的日志、计数器、列表写入和参数校验，都可能在 create_task() 返回前完成。

import asyncio

cache = {"user:1": "Alice"}

async def load_user(key):
    print("协程开始", key)  # eager 模式下在 create_task 内立即执行
    if key in cache:
        return cache[key]  # 命中缓存时不会进入事件循环调度
    await asyncio.sleep(0.01)  # 首次真正阻塞后才交回事件循环
    return "远程结果"

async def main():
    loop = asyncio.get_running_loop()
    loop.set_task_factory(asyncio.eager_task_factory)

    print("创建前")
    task = asyncio.create_task(load_user("user:1"))
    print("创建后", task.done())  # 命中缓存时这里可能已经完成
    print(await task)

asyncio.run(main())

缓存命中最容易暴露顺序差异

eager 模式的目标是减少那些本来就能同步完成的协程所产生的调度开销。缓存查询、memoization、轻量参数校验通常符合这一特征。它们也最容易让旧假设失效：调用方原以为“创建后”的语句先执行，现在协程的前置副作用可能已经发生。

哪些代码需要重点检查

不要只检查显式使用 create_task() 的一行。把工厂设置到事件循环后，同一循环中由框架或第三方库创建的任务也会使用它。重点关注：依赖日志先后判断状态、用共享列表记录启动顺序、创建任务后立刻读取计数器，以及测试中断言某个回调“尚未运行”的代码。

gather() 或 TaskGroup 对返回结果的组织规则，不等于副作用发生顺序不变。即使最终结果列表仍按输入位置组织，协程在首个阻塞点之前输出日志或修改共享状态的时刻仍可能提前。

迁移时不要依赖偶然调度

如果业务确实要求“所有任务创建完后再开始”，应使用事件、队列或锁表达同步条件，而不是依赖默认工厂的偶然起跑时机。启用 eager 工厂前，至少覆盖缓存命中、缓存未命中、同步异常和取消四条路径；任务无论何时完成，都应被 await 或显式读取结果，避免遗漏异常。

还要确认部署版本：asyncio.eager_task_factory 从 Python 3.12 开始提供。对公共库而言，最好让应用决定是否全局启用，不要在库内部悄悄替换事件循环的任务工厂。

常见问题

遇到 await 就一定会恢复默认顺序吗？

不一定。只有 await 的对象尚未完成、协程真正挂起时，剩余部分才交给事件循环；等待一个已经完成的对象可能继续同步运行。

eager 模式会让 asyncio 变成多线程吗？

不会。它改变的是协程开始执行的时点，不是线程模型。事件循环仍然采用协作式调度，同一线程里一次只执行一个任务片段。