sendfile与aio在linux内核层面互斥：sendfile依赖page cache实现零拷贝，而aio on需directio绕过缓存，二者前提冲突；nginx源码强制互斥，自动禁用其一，仅能按文件大小动态切换路径，不可协同工作。
不能配合使用。sendfile 和 aio（Linux native AIO）在 Nginx 中是互斥机制，无法同时生效于同一文件读取路径。
为什么 sendfile 和 aio 不能共存
Linux 内核层面限制了二者的技术路径：
- sendfile 是零拷贝系统调用，数据直接从磁盘页缓存（Page Cache）送入 socket 缓冲区，全程不经过用户空间，也不触发 read()；
- aio on（配合 directio）则要求绕过页缓存，用 O_DIRECT 打开文件，通过 io_submit/io_getevents 异步提交读请求——这与 sendfile 依赖页缓存的前提完全冲突；
- Nginx 源码逻辑明确：当 aio on 且 directio 生效时，自动禁用 sendfile；反之，若 sendfile on 且未启用 directio，aio 就不会被调用。
实际配置中它们如何“分工”
不是协同，而是按文件大小和场景自动切换：
- 小文件（如
- 大文件（≥ directio 阈值，如视频、归档包）：若配置了 aio on; directio 2m;，则对 ≥2MB 的文件启用异步读，小文件仍走 sendfile；
- 注意：这个“切换”是 Nginx 在单次请求中根据文件大小动态决定的，并非两种机制并行工作。
更实用的替代方案：thread pool + aio threads
如果你需要在保留 sendfile 优势的同时，避免大文件阻塞 worker 进程，推荐用线程池：
- 启用独立线程池处理阻塞型 I/O：
thread_pool default threads=16 max_queue=65536; - 在 location 中启用线程池式异步读：
aio threads;
sendfile on; - 这样 sendfile 仍用于小文件和缓存命中场景；大文件读取则交由线程池完成，worker 不阻塞，且无需 directio 或内核 AIO 支持。
日志等典型小文件场景应避开 aio + directio
例如 /var/log/ 下的 access.log、error.log：
- 体积小（KB～MB 级）、高频顺序读、高度受益于 Page Cache；
- 启用 directio 会绕过缓存，反而增加磁盘 I/O 压力；
- tail -f、gzip 日志等运维操作与 directio 不兼容；
- 正确做法是：sendfile on; tcp_nopush on;，让内核高效复用缓存数据。
