nginx 的 aio on 在 linux 下并非一开即异步，必须同时满足内核≥4.18、启用 directio 触发 o_direct、文件系统支持且对齐等条件才能真正调用 io_submit；否则静默回退同步读或启动报错。
直接说结论：Nginx 的 aio on 在 Linux 下不是“一开就异步”，它只在满足内核、文件系统、配置三重条件时才真正触发 io_submit 系统调用；否则要么静默失效，要么启动报错。
为什么 aio on 单独写在 http 块里没用
因为 aio 不是独立功能开关，而是依赖底层 I/O 路径协同工作的标记。Linux 内核的原生 AIO（io_submit）只对带 O_DIRECT 标志打开的文件生效，而 Nginx 中触发 O_DIRECT 的唯一方式是启用 directio 指令。
-
aio on单独存在时，Nginx 会尝试走 AIO 路径，但因文件未以O_DIRECT打开，最终 fallback 到同步read()，且可能在nginx -t阶段就报错 “aio is not supported” - 常见误配：
aio on; sendfile on;—— 这组配置必然冲突，sendfile依赖页缓存，directio绕过页缓存，二者互斥 - 内核版本必须 ≥ 4.18（推荐 ≥ 5.1），旧内核即使编译了
--with-file-aio，也仅支持线程池模拟（aio threads），不是真 AIO
aio on + directio 的最小有效配置
只对大文件、顺序读场景有意义，典型用于视频分发、ISO 下载等。小文件（如 HTML/JS/CSS）开启反而降低性能。
- 确认前提：
nginx -V 2>&1 | grep -o with-file-aio有输出；ls /proc/sys/fs/aio-nr可读；文件系统为 ext4（≥5.8 内核）或 XFS（推荐） - location 级配置（不能放在 http 块顶层）：
location /video/ { alias /data/video/; aio on; directio 4m; # ≥4MB 文件才走 directio + aio output_buffers 1 128k; sendfile off; # 必须关闭，与 directio 互斥 # 注意：root + index 不适用此路径，alias 更稳妥 } -
directio_alignment默认 512，XFS 下建议设为4k；若文件未按该值对齐（如普通 cp 复制），AIO 会自动退回到同步读
aio threads 是更通用的替代方案
当无法满足真 AIO 条件（如老旧内核、文件不满足对齐、ext4 无 DAX 支持），可用线程池模拟异步读，兼容性好，但本质仍是阻塞式系统调用 + 多线程调度。
- 全局定义线程池（放在 events 或 http 块外）：
thread_pool io_pool threads=32 max_queue=65536;
- 在 location 中启用：
location /static/ { alias /data/static/; aio threads=io_pool; sendfile on; # 此时 sendfile 可开启，线程池负责读取 } - 注意：
aio threads不依赖directio，也不绕过页缓存，适合混合大小文件，但 CPU 开销略高 - 验证是否启用：
strace -e trace=pread,pread64 -p $(pidof nginx)应看到大量线程池 worker 进程在调用pread64
根本不存在 aio_write 指令
Nginx 官方文档和源码中均无 aio_write，任何配置中出现该指令都会导致 nginx: [emerg] unknown directive "aio_write" 启动失败。
- 所有响应体写入（包括
sendfile、writev）均由事件循环同步驱动，Nginx 未实现基于io_submit的异步写路径 - 优化写性能靠的是：
sendfile on（zero-copy）、tcp_nopush on（满包发送）、output_buffers（减少系统调用）、日志缓冲（buffer=64k flush=5s） - 真有异步落盘需求（如上传后处理），应交由后端服务（Go/Python/Rust）完成，Nginx 只做反向代理或静态分发
最易被忽略的一点：AIO 效果高度依赖访问模式。压测时若用随机小块读或短连接高频请求，看到的只会是性能下降——它只在大文件、长连接、顺序读、I/O 成瓶颈的场景下才有价值。
