python协程的调度基于事件循环而非线程切换。事件循环作为核心协调器，监听i/o事件并管理协程执行。当协程遇到i/o阻塞时，通过await交出控制权，事件循环据此调度其他任务。i/o就绪后，事件循环恢复相应协程，实现非阻塞并发。底层依赖生成器机制与i/o多路复用技术（如epoll），协程切换仅在用户态保存少量状态，效率远高于线程。然而，协程无法处理cpu密集型任务，需协程自身主动交出控制权，否则将阻塞整个事件循环。理解生成器（yield/yield from）与事件循环机制，是掌握python协程调度的关键。
Python协程的调度核心在于事件循环（Event Loop），它像一个中央协调器，不断监听各种I/O事件和任务状态，当一个协程遇到阻塞操作时，它会将控制权交还给事件循环，事件循环则会去执行其他就绪的协程或处理其他事件，待之前的阻塞操作完成后，再将控制权交还给对应的协程，从而实现非阻塞的并发。这种切换并非真正的线程上下文切换，而是基于生成器的暂停与恢复机制，由Python运行时在用户态完成。
解决方案
要深入理解Python协程调度，我们得从它的底层逻辑——或者说，它如何“欺骗”操作系统和开发者——来切入。核心在于，Python的协程（特指
asyncio或类似框架下的）并没有真正意义上的并行执行，它依然是单线程的。那怎么实现“并发”呢？关键在于I/O操作。当一个协程发起一个网络请求或文件读写时，它通常会进入一个等待状态。传统的阻塞I/O会让整个线程卡住，但协程不是。它通过
await关键字，显式地将控制权“交出”给事件循环。
事件循环拿到控制权后，并不会傻傻地等着。它会去检查所有已注册的任务（也就是那些正在等待或已准备好执行的协程），看看有没有哪个任务已经就绪。这个检查过程依赖于底层的I/O多路复用技术，比如Linux上的
epoll、macOS上的
kqueue或者Windows上的
IOCP。这些系统调用能让事件循环同时监听成千上万个文件描述符（socket、管道等），并在它们准备好读写时通知事件循环。
立即学习“Python免费学习笔记（深入）”；
一旦某个I/O事件就绪（比如网络数据包到达），事件循环就会找到对应的协程，并将其标记为“可运行”。然后，它会选择下一个可运行的协程来恢复执行。这个恢复过程，本质上是调用生成器的
send()方法，让协程从它上次
await的地方继续往下跑。整个过程，从宏观上看是多个任务在“同时”推进，但微观上，CPU在任何一个时刻都只执行一个协程的代码。这种协作式的调度，需要协程自身“自觉”地在遇到阻塞时交出控制权，而不是被操作系统抢占。如果一个协程内部有大量CPU密集型计算，而不主动
await，那么它依然会阻塞整个事件循环，导致其他协程无法执行。这是协程模型的一个固有挑战，也是我们选择协程时需要考虑的。
Python协程的语法基石：从生成器到async/await的演进
Python的协程并非凭空出现，它的思想根植于Python的生成器（generators）。最初，我们可以利用生成器的
yield关键字来实现简单的协作式多任务，通过
yield暂停执行，通过
send()恢复执行并传递值。
yield from语句的引入，更是让生成器可以委派给另一个生成器，这为构建更复杂的协程链提供了可能，也为后来
async/await的出现铺平了道路。可以说，
yield from是
async/await语法糖的底层实现基石之一。
然而，直接使用生成器来构建异步程序，代码会显得比较晦涩，可读性也不佳，尤其是在处理异常和取消操作时更是如此。Python 3.5引入的
async和
await关键字，正是为了解决这个问题。
async def定义了一个协程函数，而
await则用于暂停当前协程的执行，等待另一个可等待对象（比如另一个协程、一个Future或一个Task）完成。它不仅仅是简单的语法糖，更重要的是，它为事件循环提供了一个明确的暂停点和恢复点。当你
await一个操作时，你实际上是在告诉事件循环：“我在这里要等一下，你可以去干别的了，等这个操作有结果了再回来找我。”这种显式的标记，让异步代码的结构变得清晰，也更符合人类的思维习惯。从源码层面看，
async def定义的函数会返回一个
coroutine对象，这个对象本质上就是一个特殊的生成器迭代器，而
await操作则会调用其内部的
__await__方法，最终还是回到了生成器协议上。所以，理解生成器，是理解Python协程调度机制的必经之路。
事件循环的心脏：I/O多路复用如何驱动协程的生命周期
如果说协程是舞台上的演员，那事件循环就是导演，而I/O多路复用技术则是导演手中的对讲机，让它能同时关注多个演员的状态。在Python的
asyncio库中，事件循环的实现，特别是其核心的
SelectorEventLoop（或在Unix-like系统上的
_UnixSelectorEventLoop），正是依赖于操作系统提供的I/O多路复用机制，如
select、
poll、
epoll（Linux）或
kqueue（macOS/BSD）。
这些系统调用的强大之处在于，它们允许一个进程同时监听多个I/O事件（例如，多个socket连接的读写就绪）。事件循环启动后，它会进入一个无限循环，调用这些多路复用函数，阻塞在那里，直到有I/O事件发生或者达到设定的超时时间。一旦有事件就绪（比如，客户端发来了数据，或者服务器可以发送数据了），多路复用函数就会返回，并告知事件循环是哪个文件描述符发生了什么事件。
事件循环拿到这些信息后，会根据之前注册的回调（通常是对应的协程任务），将控制权交还给相关的协程。举个例子，当一个协程执行
await reader.read()时，它会注册一个回调到事件循环中，然后暂停自身。当网络数据真正到达时，
epoll会通知事件循环，事件循环找到对应的回调，唤醒该协程，让它从
await点继续执行。这个过程是高效的，因为它避免了为每个连接都创建一个线程或进程所带来的巨大开销，也避免了忙等（busy-waiting）。可以说，I/O多路复用是现代高性能网络服务的基础，也是Python协程能够实现高并发的关键所在。没有它，事件循环就无法高效地感知外部世界的变化，协程调度也就无从谈起。
协程的切换艺术：yield from与await的背后机制与上下文管理
协程的“切换”并非操作系统层面的上下文切换，而是一种用户态的协作式调度。理解这一点，是理解Python协程效率的关键。当一个协程遇到
await表达式时，它会暂停自身的执行，并将控制权交还给调用它的上层协程或事件循环。这个过程，在Python内部，实际上是基于生成器的
yield或
yield from机制实现的。
具体来说，
async def函数在被调用时，并不会立即执行其内部代码，而是返回一个
coroutine对象。这个对象是一个可迭代的“未来”（future），你可以把它想象成一个特殊的生成器。当你
await这个
coroutine对象时，事件循环（或另一个协程）会开始“驱动”它，通过类似调用生成器
send(None)的方式，让它执行到下一个
await点。每当遇到一个
await，协程就会
yield出当前等待的对象（通常是一个
Future或
Task），并将自身的执行状态（包括局部变量、指令指针等）“冻结”起来。
这个“冻结”和“恢复”的过程，就是协程的上下文管理。Python解释器会保存协程的当前栈帧状态，以便在它被唤醒时能够准确无误地从上次暂停的地方继续执行。这与线程的上下文切换不同，线程切换需要保存和恢复完整的CPU寄存器、程序计数器、栈指针等，并涉及内核态的介入，开销较大。而协程的切换，仅仅是保存和恢复少量与生成器状态相关的Python对象，完全在用户态完成，因此其开销极小，这也是协程能够支持高并发任务的关键原因之一。
举个不那么严谨但形象的例子：线程切换就像两个人同时在用一台电脑，需要频繁地保存和加载各自的桌面环境；而协程切换则像一个人在写多个剧本，写到某个地方卡住了，就放下笔去写另一个，等有灵感了再回来接着写。这个过程中，他只需要记住上次写到哪了，而不需要重新“启动”整个大脑。这种轻量级的切换，正是Python协程高效的秘密。
