nginx event loop 不处理文件 i/o，仅调度网络事件；文件读取默认同步，异步需启用 aio 或使用 sendfile：aio 由内核独立完成并通知，sendfile 则通过零拷贝实现高效传输。
Nginx 的 Event Loop 并不直接处理文件读取的异步操作，它只负责调度网络 I/O 事件；文件读取（磁盘 I/O）默认是同步的，异步支持需额外启用且由独立机制实现。
Event Loop 本身不监听文件描述符
Linux 下 epoll 等事件驱动机制无法监听普通文件 fd —— 文件不支持就绪通知。因此 Nginx 的 Event Loop 永远不会把 open() 后的文件句柄注册进 epoll 实例，也就不会为其触发 read 事件回调。
这意味着：即使启用了 AIO，Event Loop 仍只管 socket、监听 fd 等网络相关事件；文件读取是否异步、何时完成、如何通知，完全交由内核 AIO 子系统或 sendfile 零拷贝路径处理，与 Event Loop 分离。
AIO 是独立于 Event Loop 的内核机制
当配置 aio on; 且满足条件（Linux 内核 ≥2.6.22、使用 directio、文件对齐等）时，Nginx 调用 io_submit() 发起异步读，之后立即返回，不阻塞 worker 线程。
- 内核在后台线程中完成磁盘读取，并通过 io_getevents() 或信号（如 SIGIO）通知完成
- Nginx 内部用专用线程池或定时器轮询检查 AIO 完成状态，而非靠 Event Loop 唤醒
- 读取完成后，Nginx 才继续走 HTTP 响应流程，比如调用 ngx_http_send_header() 或 ngx_http_writer()
sendfile 是更常用、更轻量的“伪异步”替代方案
对静态文件服务，Nginx 默认优先使用 sendfile on;，它绕过用户态内存拷贝，由内核直接将文件内容 DMA 到 socket 发送队列。
- 整个过程无需用户态读缓冲区，也不触发 read() 系统调用，自然避开阻塞问题
- 不需要 AIO 那样的复杂配置和限制（如 directio、文件对齐），兼容性好、开销低
- 虽非严格意义上的异步 I/O，但在效果上等同于“无感知的高效文件传输”，且完全由内核原子完成
未启用 AIO 时，文件读取就是同步阻塞
若没配 aio 或不满足条件，Nginx 使用标准 read() 读取文件：
- worker 线程会短暂阻塞，直到数据从磁盘加载到内存
- 为缓解影响，Nginx 依赖 open_file_cache 缓存文件句柄和元信息，减少 open() 和 stat() 开销
- 小文件常被缓存进内存，实际读取很快；大文件则容易暴露阻塞风险，此时才真正需要 AIO 或 sendfile
