Python asyncio.create_task eager_start 如何影响调度

asyncio.create_task() 的 eager_start 决定协程是在创建任务的调用内先执行，还是交给事件循环稍后调度。设置为 True 时，协程会在创建调用中运行到第一次阻塞；如果在阻塞前已经返回或抛出异常，任务会直接完成，不再进入事件循环的就绪队列。设置为 False 时，任务等待后续调度；不传或使用 None 时，则沿用当前事件循环任务工厂的模式。

官方文档：https://docs.python.org/3/library/asyncio-task.html

把 eager_start 看成“创建任务时是否抢先跑一小段”的语义开关，而不是简单的性能开关。它改变的是创建点附近的执行顺序，最容易影响日志顺序、共享状态初始化和任务之间的可观察先后关系。

先分清任务创建和协程启动

调用协程函数只会得到一个协程对象，真正把它交给事件循环的是 create_task()。在默认的延后调度模式下，create_task() 返回任务对象后，当前协程还可以继续执行，新的任务再由事件循环安排运行。

import asyncio

async def worker():
    # 这里的代码属于协程正文，只有任务开始运行时才会执行
    print("worker: start")
    await asyncio.sleep(0)
    # 第一次 await 之后，控制权回到事件循环
    print("worker: resumed")

async def main():
    # 不指定 eager_start 时，使用默认任务工厂的调度模式
    task = asyncio.create_task(worker())
    # 当前协程先继续执行，task 的后续运行交给事件循环
    print("main: task created")
    # 保留任务引用，并等待它完成
    await task

asyncio.run(main())

这里的关键不是“创建任务就立刻执行”，而是任务何时获得第一次运行机会。后续章节讨论的 eager_start，正是把这次机会前移到创建任务的调用内部。

eager_start=True 会执行到哪里

当事件循环正在运行且 eager_start=True 时，任务构造阶段会立即启动协程，直到协程第一次阻塞。常见的阻塞点是等待尚未完成的 Future、定时器或其他需要事件循环继续推进的 awaitable。

因此，创建调用之后的下一行代码可能观察到两种不同状态：如果协程在首次 await 前已经返回，任务已经完成；如果运行到一个真正需要等待的点，任务会暂停并在后续继续由事件循环调度。这个行为改变了原有的任务执行语义，不能只用“少一次排队”来理解。

import asyncio

async def fast_path():
    # 没有阻塞点时，eager_start=True 可能在创建调用内完成
    return "cache-hit"

async def slow_path():
    # 先执行到这里，再因等待未完成的定时器而暂停
    await asyncio.sleep(0.01)
    return "io-result"

async def main():
    # 显式开启：先运行 fast_path，再返回 Task 对象
    fast = asyncio.create_task(fast_path(), eager_start=True)
    # 显式开启：运行到 sleep 的阻塞点后才回到当前协程
    slow = asyncio.create_task(slow_path(), eager_start=True)
    # 读取结果前仍然要等待任务；创建时完成的任务也应被正常 await
    print(await fast, await slow)

asyncio.run(main())

不要把这段示例理解成固定的全局顺序保证。它只说明同步执行窗口的边界：eager_start=True 影响创建点附近的可观察行为，但不会让后续异步部分脱离事件循环，也不会替你设计任务之间的依赖。

False、True 和 None 怎么选

如果代码依赖“创建任务后当前协程先完成某个共享状态写入”，应优先使用默认延后语义或显式 False，再通过锁、事件或任务依赖表达真正的同步关系。如果任务是纯缓存命中路径，并且团队已经接受创建时执行的语义变化，才考虑 True。

None 为什么会受到任务工厂影响

官方文档说明，eager_start 未传入时会使用 loop.set_task_factory() 设置的模式。Python 还提供 asyncio.eager_task_factory，用于让协程在 Task 构造期间同步开始；只有遇到阻塞时，任务才会被安排到事件循环继续运行。

import asyncio

async def cached_lookup():
    # 这个示例代表可能直接命中内存缓存的短协程
    return "cached"

async def main():
    loop = asyncio.get_running_loop()
    # 任务工厂统一决定未显式指定 eager_start 时的启动模式
    loop.set_task_factory(asyncio.eager_task_factory)
    # None 表示沿用工厂配置，而不是强制关闭或开启
    task = asyncio.create_task(cached_lookup(), eager_start=None)
    # 保持对任务的引用，并以 await 取得结果
    print(await task)

asyncio.run(main())

任务工厂是循环级配置，影响范围比单个 create_task() 调用更大。把它用于缓存型短协程前，要先确认现有代码没有依赖“所有任务都先排队”的顺序；否则一个看似局部的优化可能让初始化、日志或回调顺序发生变化。

版本兼容和任务生命周期边界

asyncio.create_task() 的 eager_start 参数是 Python 3.14 的新增变化；asyncio.eager_task_factory 则在 Python 3.12 引入。面向多个 Python 版本发布库时，不要无条件把 eager_start 传给旧版本的 create_task()，可以按运行时版本选择参数，或统一使用项目支持版本中的任务工厂方案。

另外，create_task() 返回的任务应保留强引用并在需要时等待。事件循环只保留弱引用，临时创建后不保存对象可能导致任务在完成前被回收；如果任务属于一组有关联的工作，优先考虑 TaskGroup 来集中等待并传播异常。

import asyncio
import sys

async def work():
    # 业务协程只演示任务生命周期，不依赖具体外部服务
    await asyncio.sleep(0)
    return "done"

async def main():
    # 版本分支只决定是否传入 create_task 的新参数
    if sys.version_info >= (3, 14):
        task = asyncio.create_task(work(), eager_start=False)
    else:
        # 旧版本使用默认创建方式，避免传入不存在的关键字参数
        task = asyncio.create_task(work())
    # 显式等待任务，确保异常和返回值不会被遗忘
    print(await task)

asyncio.run(main())

常见误区

• 把 eager_start 当成固定加速开关。它可能减少短协程的调度开销，但同时改变执行语义和任务顺序；先确认业务是否允许这种变化。
• 认为 True 会让整个协程同步完成。它只执行到首次阻塞；一旦需要等待，后续仍由事件循环推进。
• 以为 None 等同于 False。None 会读取任务工厂配置，循环可能已经启用了 eager_task_factory。
• 忽略任务引用和异常。无论采用哪种启动模式，都要保存 Task，并用 await、TaskGroup 或明确的异常处理取得结果。

相关问题

eager_start=True 是不是 Python 3.12 就能传给 create_task？

不是。官方 asyncio 文档标注 create_task() 的 eager_start 参数在 Python 3.14 增加；Python 3.12 已经有 eager_task_factory，但两者不是同一个入口。

协程没有 await 时为什么更容易看出 eager_start 的差异？

因为它可能在 Task 构造阶段直接返回或抛出，任务就不会进入事件循环的后续调度；有阻塞点的协程则只会先运行到该阻塞点。

生产代码应该统一使用 eager_start=True 吗？

不应该。先按共享状态、日志顺序、缓存命中比例和版本支持范围评估；如果只是为了表达依赖关系，应使用事件、锁、TaskGroup 或显式等待，而不是依赖隐含的创建顺序。