1 引言
上一篇文章中我们已经知道，Event Loop 是异步程序的大脑，负责任务调度，且它绝对不能被阻塞。但你可能会好奇：当 Event Loop 在等待一个网络请求或文件读写时，它是在原地“转圈圈”盲目轮询，还是在闭目养神？
这就引出了我们今天要聊的底层功臣——Selector（选择器）。如果说 Event Loop 是指挥家，那么 Selector 就是指挥家的耳朵。
2 异步 I/O 模型：Reactor 和 Proactor
asyncio 实际上在底层适配了两种截然不同的“反应模式”：Reactor 和 Proactor。
处理异步 I/O 操作时，根据操作系统底层机制的不同，主要分为以下两种模式：
- Reactor 模式（反应堆模式）：主要用于 Unix/macOS 系统。它的逻辑是“对就绪状态做出反应”。当系统发现某个文件描述符（FD）已经准备好进行读写操作时，它会通知 Event Loop，由 Loop 来触发相应的回调函数。
- Proactor 模式（前摄器模式）：主要用于 Windows 系统。它基于 I/O 完成端口（IOCP）。与 Reactor 不同，Proactor 是“对完成事件做出反应”。IOCP 允许一组线程等待 I/O 完成事件。当一个异步 I/O 操作真正执行完毕时，其中一个线程会处理该事件。如果事件瞬间爆发，超过了线程的处理能力，IOCP 会自动排队等待后续处理。
虽然底层机制千差万别——BSD/macOS 使用 kqueue，Linux 使用强大的 epoll，Solaris 使用 dev/poll，而 Windows 则使用 Select 或 IOCP。但作为开发者，我们不需要为每个系统写一套逻辑。
Python 的 selectors 模块提供了一个高级的、平台无关的接口。它会自动探测当前平台上最高效的系统调用，并将其统一封装。
如果你需要手动指定一个特定的选择器（例如在调试时强制使用最基础的 Select），可以参考如下配置：
import asyncio
import selectors # 显式使用 Select 机制的选择器
selector = selectors.SelectSelector()
# 将该选择器注入到 Event Loop 中
loop = asyncio.SelectorEventLoop(selector)
asyncio.set_event_loop(loop)
3 源码视角的家族谱系
在 asyncio 的内部实现中，这些事件处理器的继承关系非常严谨。我们可以通过下面这张结构图清晰地看到从抽象接口到具体平台实现的演变：
graph TDsubgraph events.pyA[Abstract*]endsubgraph base_events.pyB[Base*]endsubgraph selector_events.pyC[BaseSelector*]endsubgraph proactor_events.pyD[BaseProactor*]endsubgraph unix_events.pyE[Selector*]endsubgraph windows_events.pyF[Selector*]G[Proactor*]end%% 关系A --> BB --> CB --> DC --> EC --> FD --> G
- Abstract/Base 层定义了 Loop 的基本行为。
- Selector 系列 实现了基于“就绪通知”的 Reactor 模式，覆盖了 Unix 家族和 Windows 的基础兼容模式。
- Proactor 系列 则专为 Windows 的 IOCP 高效模型设计。
4 总结
Selector 不仅仅是一个简单的过滤器，它是 asyncio 实现跨平台高性能的关键。它通过 Reactor 模式适配了类 Unix 的灵活性，通过 Proactor 模式挖掘了 Windows 的并发潜力。