nginx事件循环跨平台逻辑一致，差异仅在于底层i/o多路复用机制：linux用epoll（et模式，o(1)复杂度），freebsd/macos用kqueue（语义精细，近lt），windows回退select/poll（o(n)，限fd数），性能上限由系统机制决定。
Nginx 的 Event Loop 机制在不同操作系统下核心逻辑一致，但底层实现依赖系统提供的 I/O 多路复用接口，因此关键差异集中在事件驱动模型的选择与行为细节上。
Linux 下默认使用 epoll，高效且支持边缘触发（ET）
epoll 是 Linux 内核原生的高性能事件通知机制。Nginx 在 Linux 上默认启用 EPOLLET（边缘触发），只需一次注册即可长期监听，内核仅在 fd 状态发生变化时通知（如从不可读变为可读），减少重复唤醒。它支持海量连接（数十万级），时间复杂度为 O(1) 级别，适合高并发生产环境。
- 通过
nginx -V 2>&1 | grep epoll可确认是否启用 -
events块中use epoll;可显式指定（通常无需手动设置） - 注意：ET 模式要求应用层必须一次性读完或写完数据，否则可能漏事件
FreeBSD/macOS 下使用 kqueue，语义更精细、支持更多事件类型
kqueue 是类 BSD 系统的事件通知框架，Nginx 利用其过滤器（filter）机制区分 read/write/error/timeout 等子事件，比 epoll 更灵活。它同样支持水平触发（LT）和边缘语义，但默认行为更接近 LT。
- 支持文件变更、进程状态、信号等非网络事件（Nginx 当前仅用于网络 I/O）
- 事件注册开销略高于 epoll，但稳定性与兼容性极佳
- macOS 用户可通过
nginx -V | grep kqueue验证
Windows 和旧系统回退到 select/poll，性能明显受限
Windows 不支持 epoll 或 kqueue，Nginx 在其上只能使用 select（或 poll，取决于编译选项）。该机制每次调用都要遍历全部监控的 fd，时间复杂度为 O(n)，且最大文件描述符数通常限制在 1024 或 65535（取决于 Windows 版本和编译参数）。
- 单 worker 进程实际承载能力远低于 Linux（通常建议不超过 1000 并发）
-
user指令无效，无权限降权机制，安全性与资源隔离较弱 - 日志、静态文件读写不经过内核异步路径，I/O 效率更低
Event Loop 行为本身跨平台保持统一
无论底层是 epoll、kqueue 还是 select，Nginx 的事件循环结构不变：
- 单 worker 进程 = 单线程 + 单 Event Loop
- 主循环同步执行：等待就绪 → 搬运事件 → 依次调用 handler
- 所有网络操作（accept/read/write/close）均封装为事件，按需注册、动态挂载 handler
- 定时器、连接超时、清理任务全部纳入同一调度体系，使用红黑树管理
本质上，OS 差异只影响“如何得知事件就绪”，不影响 Nginx 如何组织连接、解析请求或分发处理逻辑。真正决定性能上限的，是底层 I/O 机制的能力边界，而非 Nginx 自身代码。
