Nginx 中 AIO 与 DirectIO 是强绑定协同机制：directio 4m 启用 Direct I/O 并触发 AIO（仅对 ≥4MB 文件），小文件走 sendfile+页缓存；二者可共存，Nginx 自动分流。
要让 Nginx 对不同大小文件自动选择最优 I/O 路径，关键不是“AIO 对比 DirectIO”，而是理解二者在 Nginx 中是强绑定、协同工作的机制：AIO（aio on）在 Linux 上**必须配合 DirectIO（directio）才能生效**，且只作用于达到阈值的大文件；小文件则默认走页缓存 + sendfile 路径。配置目标是让两者无缝衔接，而非互斥切换。
明确 AIO 和 DirectIO 的关系
AIO 在 Nginx 中不是独立的异步读取能力，它依赖内核的 io_submit/io_getevents 接口，而该接口要求文件以 O_DIRECT 方式打开——这正是 directio 指令的作用。没有 directio，aio on 在 Linux 下基本无效（FreeBSD 行为不同）。因此：
-
directio 4m表示：≥ 4MB 的文件启用 Direct I/O，并在此基础上触发 AIO 异步读取 - sendfile + 内核页缓存处理（更高效）
-
aio on和sendfile on可同时开启，Nginx 会按文件大小自动分流：小文件用 sendfile，大文件用 aio+directio
典型分层配置示例
以下配置实现真正的差异化策略，适用于视频、下载等混合静态资源场景：
location /static/ {
alias /var/www/static/;
<pre class="brush:php;toolbar:false;"># 共享基础优化
sendfile on;
tcp_nopush on;
open_file_cache max=1000 inactive=60s;
open_file_cache_valid 60s;
# 差异化 I/O 分流起点
directio 4m; # ≥4MB 文件启用 Direct I/O（隐含触发 AIO）
aio on; # 启用内核 AIO 支持（仅对 directio 生效的文件起作用）
output_buffers 1 128k;
# ⚠️ 注意：无需关闭 sendfile —— Nginx 自动判断使用路径}
该配置下：
- 一个 2MB 的 JS 文件 → 走
sendfile+ 页缓存（低延迟、高命中） - 一个 50MB 的 MP4 文件 → 走
aio+directio（绕过页缓存，避免内存挤占，DMA 直传）
必须验证和规避的常见陷阱
即使配置写对，系统层面不支持也会导致 AIO 静默失效或降速：
- 检查 Nginx 编译是否含 AIO：
nginx -V 2>&1 | grep -o with-file-aio（有输出才有效） - 确认内核支持：
ls /proc/sys/fs/aio-nr存在即表示 AIO 子系统就绪 - 文件系统需支持 Direct I/O：XFS 全面支持；ext4 需内核 ≥ 5.8 且挂载时无
noatime,nobarrier冲突 - 日志中若出现
aio_read() failed或kevent() reported that event is not supported，说明文件系统权限或挂载选项不兼容
替代与补充策略（更实用的优化方向）
对多数 Web 服务而言，精细化调优 AIO/DirectIO 的收益有限，而以下措施见效更快、风险更低：
- 用
open_file_cache缓存 inode 和文件句柄，显著降低小文件stat()/open()开销 - 启用
tcp_nopush on+tcp_nodelay on组合，优化 TCP 包发送节奏 - 将静态资源托管到 CDN，从网络边缘卸载 90% 以上流量，效果远超单机 I/O 调优
- 如确需通用异步能力（如 SSL 握手、proxy_read），优先考虑
aio threads=xxx线程池方案，它不依赖内核 AIO，兼容性更好
