用大白话讲清楚：协程到底是个什么东西？

jianfeng huang — Sat, 03 Oct 2026 00:41:58 +0000

先把结论摆出来，不绕弯子：

普通函数是「一次性」的：一旦调用，就必须一路跑到 return 或者抛异常。
协程是「可以暂停、可以恢复」的函数：它跑到一半能把控制权交出去，等条件满足了再回来接着跑。

协程不是什么新奇的线程，也不是什么黑魔法。它本质上就是一种能把执行过程切成小段、并且每段的边界由代码自己说了算的调用方式。

下面我把这个句子拆开讲。

一、先看你熟悉的那个世界

平时写的函数是这样的：

def pay(order):
    check_stock(order)      # 必须执行完
    charge(order)           # 必须执行完
    send_email(order)       # 必须执行完
    return "ok"

调用 pay(order)，Python 就得从第一行走到最后一行。中间 send_email 要等 3 秒，这 3 秒里整个线程就卡在那儿，什么也干不了。

这是「一次性」的含义：函数的执行过程属于调用者，函数自己交不出控制权。

问题就出在这里。后端服务大量时间不是在算，而是在等 —— 等数据库、等第三方接口、等磁盘。线程在等的过程中，明明什么都没干，却占着一个线程资源不放。

二、协程：让函数做到一半先撤

想象你在厨房炒菜，炒到一半发现酱油没了。你有两种做法：

线程的做法：关火，站在灶台前死等外卖送酱油，这期间灶台被你占着，别人没法用。
协程的做法：把锅放一边，跟厨房里的其他人说一句「我缺酱油，谁先用灶」，然后去干别的；酱油到了再回来接着炒。

第二种做法里，那个「炒菜的过程」就是协程：它是一个可以被打断、被挂起、之后还能从断点继续的过程。

Python 里最原始的协程形态是生成器，yield 就是那个「暂停点」：

def cook():
    print("1. 热锅下油")
    yield "酱油没了，我先去买"      # 在这里「暂停」，控制权交回调用方
    print("2. 酱油回来了，接着炒")
    yield "炒好了，装盘"
    print("3. 上桌")

c = cook()
print("调用 cook() 拿到的不是菜，而是一个对象:", c)
print("第一次 next ->", next(c))
print("……等待过程中，我可以去顺手把米饭煮上")
print("第二次 next ->", next(c))

真实输出：

调用 cook() 拿到的不是菜，而是一个对象: <generator object cook at 0x100e06ec0>
1. 热锅下油
第一次 next -> 酱油没了，我先去买
……等待过程中，我可以去顺手把米饭煮上
2. 酱油回来了，接着炒
第二次 next -> 炒好了，装盘

注意两点，这是理解协程的关键：

cook() 调用完，函数体一行都没执行。 它只是造出了一个对象，真正跑起来要靠 next() 喂它。所以协程天生是「懒」的、可被外部驱动的。
中间那句「顺手把米饭煮上」是插在两段之间的。 也就是说，协程暂停的这段时间，调用方可以自由地去干别的事。这就是「让出控制权」的全部含义。

三、async/await 只是把这套东西变得好用了

生成器 + yield 太反直觉，写起来像在拼装零件。所以 Python 3.5 给了 async/await 语法糖：

async def fetch(name, delay):
    print(f"[{name}] 开始请求")
    await asyncio.sleep(delay)      # 关键：等待时把控制权交还给事件循环
    print(f"[{name}] 返回了")
    return name

await asyncio.sleep(1) 和 yield 在做同一件事：「我这儿要等 1 秒，事件循环你先去忙别的，1 秒后再回来叫我。」

而那个「忙着调度别人的家伙」就是事件循环（event loop）。你可以把它理解成厨房里的厨师长：谁在等东西，就把谁的锅端下来，把灶让给下一个能立刻干活的人。

跑一下两个协程：

async def main():
    start = time.perf_counter()
    await asyncio.gather(fetch("A", 1), fetch("B", 1))
    print(f"总耗时 {time.perf_counter() - start:.2f}s")

asyncio.run(main())

[A] 开始请求
[B] 开始请求
[A] 返回了
[B] 返回了
总耗时 1.00s

两个各等 1 秒的任务，总共只花了 1 秒。因为 A 在等的时候，B 已经把请求发出去了 —— 谁都没闲着。

四、为什么不能直接写 `time.sleep`

这是最容易踩的坑，也是最能说明协程本质的一段。把上面的 await asyncio.sleep(1) 换成阻塞的 time.sleep(1)：

async def fetch(name, delay):
    print(f"[{name}] 开始请求")
    time.sleep(delay)               # 阻塞式睡眠：整个线程都停在这
    print(f"[{name}] 返回了")

结果立刻退化：

[A] 开始请求
[A] 返回了
[B] 开始请求
[B] 返回了
总耗时 2.01s

变回串行了。原因很直白：time.sleep 不会把控制权交给事件循环，它让整个线程真真切切地睡着了。线程睡着了，事件循环也被冻住，谁都没法调度。

所以记住这句话，比背十遍定义管用：

协程的「并发」不是凭空产生的，它靠的是「每个任务在等待时主动让出」。

一旦有谁不让出（time.sleep、同步的 requests、CPU 密集的循环），整条流水线就全堵死了。这是协程和线程最本质的分歧，下一节展开。

五、和线程到底差在哪：谁决定「换人」

线程是抢占式的：切换的时机由操作系统内核说了算，程序自己管不着。哪怕你写了个死循环，内核照样会把 CPU 抢走分给别人：

  t=0.32s 另一个线程照样拿到了 CPU（内核抢走的）
  t=1.50s 忙线程自己跑完了

协程是协作式的：切换只发生在代码显式 await（或 yield）的地方。没有 await，就没有切换。好处是切换点全都在你眼皮底下，天然没有竞态、不用到处加锁；代价是你必须自己保证「该让出的时候让出了」。

一句话对比：线程的调度权在内核，协程的调度权在你自己手里。

同样重要的是：协程跑在单个线程上，所以它不提供任何并行能力。它的价值是「一个线程处理更多 IO 等待」，而不是「让计算更快」。CPU 密集的活儿交给协程，只会是负优化 —— 因为它把多核白白浪费了。

六、类比在哪里会失效

用「炒菜换灶」打比方很好懂，但要小心这两点，别被比喻带歪：

协程不是「半个线程」。 它没有自己的栈切换开销那么大，也不是由操作系统管理的对象，它就是一堆被事件循环驱动的 Python 对象（coroutine / Task）。
不是「真的同时在做」。 在任意一个瞬间，一个事件循环里只有一段协程代码在跑。看起来的「同时」是多个任务在等待点之间快速交替的结果。

顺手验证一下「协程是懒的」这件事：

coro = hello()          # 注意：没有任何输出
print("hello() 只是造出了一个协程对象:", coro)

hello() 只是造出了一个协程对象: <coroutine object hello at 0x103e0af80>

不 await 它，它就一直躺着不动 —— 这也是「coroutine was never awaited」这条警告的来源。

七、那什么时候别用协程

CPU 密集：图像处理、加密、大量计算 —— 用多进程，协程帮不上忙，还会拖慢。
生态是同步的：依赖一堆只提供同步 SDK 的库，为了用协程到处 run_in_executor，复杂度比收益高。
团队不熟：协程的坑（阻塞调用混进来、忘记 await、超时没设）在线上会以「整个服务卡死」的形式出现，排查成本不低。

八、一张表收尾

	进程	线程	协程
调度者	操作系统内核	操作系统内核	你自己的代码 / 事件循环
切换时机	抢占式，随时	抢占式，随时	协作式，只在 `await` 处
切换成本	高	中	低
真并行	是（多核）	是（多核，受 GIL 影响）	否，单线程交替
适合	CPU 密集	混合负载	IO 密集、高并发等待

回到最初那句话

协程就是一个能暂停、能恢复的函数，加上一个负责「在谁等待时把执行权交给别人」的调度器（事件循环）。

async/await 只是语法糖，生成器的 yield 才是它最朴素的形态；而「并发」这件事，来自每个任务在等待时主动让出，不是来自多出来的 CPU。

搞清这两点，面对 coroutine was never awaited、event loop is closed、以及「为什么我加了 async 反而更慢了」这三类报错，你基本都能自己推出原因了。

DEV Community: jianfeng huang