nginx在linux、freebsd/macos、windows上均使用非阻塞io，但事件驱动机制不同：linux用epoll，freebsd/macos用kqueue，windows依赖select或iocp；非阻塞是基础，事件驱动才是高并发关键。
nginx 使用的非阻塞 IO（Non-blocking IO）在 Linux、FreeBSD、macOS 等主流系统上底层行为一致，但具体实现细节和配套机制存在关键差异——主要体现在系统调用接口、事件通知模型以及内核对高并发连接的支撑能力上。这些差异直接影响 nginx 的性能表现和配置调优方向。
Linux：epoll 是默认且最成熟的支撑
Linux 下 nginx 默认启用 epoll 作为事件驱动引擎，它天然适配非阻塞 socket。epoll 支持边缘触发（ET）和水平触发（LT）两种模式，配合 O_NONBLOCK 设置后，可高效监听成千上万连接的读写就绪状态。内核通过红黑树 + 就绪链表管理 fd，避免了传统 select/poll 的遍历开销。
- 设置非阻塞需显式调用
fcntl(fd, F_SETFL, O_NONBLOCK) - nginx 在启动时自动为所有监听 socket 和 accept 后的 client socket 设置该标志
- epoll_wait 返回后，nginx 仅处理真正就绪的 fd，不轮询；这与纯非阻塞轮询有本质区别
FreeBSD/macOS：kqueue 提供更细粒度的事件控制
FreeBSD 和 macOS 使用 kqueue 替代 epoll。kqueue 不仅支持 socket 读写就绪，还能监听文件变更、进程退出、定时器等事件，语义更丰富。其 EVFILT_READ/EVFILT_WRITE 过滤器与非阻塞 socket 协同良好，同样避免线程阻塞。
- kqueue 允许注册一次性事件（EV_ONESHOT），适合短连接场景
- 对 TCP 连接建立完成（EVFILT_CONNECT）的支持比 epoll 更直接
- nginx 在这些系统上会自动选用 kqueue，并保持相同的非阻塞 socket 行为逻辑
Windows：WSAEventSelect / IOCP 模式下行为不同
Windows 不支持原生 epoll 或 kqueue，nginx 官方版本不直接支持 Windows 生产部署（官方推荐使用 WSL 或 Linux 容器）。若通过第三方移植版运行，通常依赖 select() 或基于 Windows Sockets 的 IOCP（异步 I/O）。此时“非阻塞”含义发生偏移：
- select 模型下仍需轮询，效率低，且最大 fd 数受限（默认 64 或 1024）
- IOCP 实际属于异步 IO 模型（AIO），与 Unix/Linux 的非阻塞 + 多路复用有原理级差异
- nginx 在 Windows 上无法启用真正的 epoll/kqueue 级别事件驱动，非阻塞 socket 仍存在，但事件分发层性能瓶颈明显
共性：非阻塞是基础，事件驱动才是关键
无论哪个系统，nginx 都坚持将 socket 设为 O_NONBLOCK —— 这是所有后续高效处理的前提。但真正让 nginx 高并发的关键，不是“非阻塞”本身，而是它所绑定的事件通知机制（epoll/kqueue/select）。没有事件驱动，纯非阻塞轮询在连接数上升后 CPU 使用率会急剧飙升，失去实用价值。
- 非阻塞 IO 是必要条件，不是充分条件
- nginx 的配置项如
use epoll;或use kqueue;显式指定事件模型，影响实际行为 - 即使系统支持更优模型，若未正确启用（如 Linux 上未配置 use epoll），nginx 可能回落到 select，性能显著下降
