将Python同步代码迁移到asyncio：asyncio.run与asyncio.Runner的差异对比

你的场景回顾 #

你正在将Python 3代码从全同步迁移到半异步架构——读消息的部分暂时无法兼容asyncio，所以保留了同步循环：

for message in read_messages():
  handle_message(message)

现在你把handle_message改成了异步函数handle_message_async，希望继续逐个处理消息，同时在单条消息的处理逻辑里使用asyncio能力，因此纠结于两种调用方式的差异。

两种方式的核心差异分析 #

1. 事件循环的生命周期（Setup/Teardown）

这是两者最关键的区别：

• asyncio.run：每次调用都会创建一个全新的事件循环，执行完异步函数后，会立即关闭这个循环并清理所有相关资源（包括未完成的任务、异步句柄、绑定的资源等）。简单说就是“一次调用，一套全新循环，用完就扔”。
  对应你的代码：

  for message in read_messages():
    asyncio.run(handle_message_async(message))
  

  每处理一条消息，都要重新初始化事件循环，处理完就销毁，反复的创建销毁会带来额外开销。如果你的handle_message_async里用到了需要复用的异步资源（比如HTTP客户端会话、数据库连接池），每次都会被销毁，下次处理消息又要重新建立，效率很低。

• asyncio.Runner()：通过with语句创建一个Runner实例后，整个循环内复用同一个事件循环。Runner会在with块开始时初始化一次循环，直到with块结束才会关闭循环、清理资源。
  对应你的代码：

  with asyncio.Runner() as async_runner:
    for message in read_messages():
      async_runner.run(handle_message_async(message))
  

  所有消息的处理都在同一个事件循环里执行，避免了重复创建销毁循环的开销，适合需要复用异步资源的场景。

2. 异常处理的差异

两者都会把异步函数中抛出的异常同步抛回给上层的同步代码，这一点是一致的，但细节上有区别：

• asyncio.run会在循环关闭时检查是否有未处理的任务异常，如果有会直接抛出；而Runner在每次调用run()时就会立即抛出当前异步函数的异常，同时在with块结束时，默认会检查是否有未完成的任务（可以通过Runner的cleanup参数调整这个行为）。
• 两者对KeyboardInterrupt这类信号的处理逻辑基本一致，但Runner提供了更灵活的参数（比如handle_signals）来控制是否自动处理信号。

针对你的场景的建议 #

如果你的handle_message_async不需要复用任何异步资源（每条消息的处理完全独立），asyncio.run也能工作，但效率不如Runner；如果你的异步处理逻辑里有需要复用的资源（比如数据库连接、缓存客户端），优先选择asyncio.Runner()的方式，它能帮你减少不必要的资源重建开销，让整体处理更高效。

备注：内容来源于stack exchange，提问作者Ido Ran