Nginx 通过 location 级 read_ahead 指令启用内核预读，需配合 sendfile on 和 open_file_cache 使用，仅适用于 Linux 上顺序读取的大静态文件，推荐设为 1m 或 2m。
要让 Nginx 对静态资源做预取（即提前读入内存以加快后续响应），核心是启用 read_ahead 指令，并配合 sendfile 和文件缓存机制协同工作。Nginx 本身不支持类似浏览器的 <link rel="prefetch"> 这类主动触发式预取，但可通过内核级预读提升大文件（如 JS、CSS、视频）的首次读取性能。
启用 read_ahead 预读机制
read_ahead 是 Nginx 的 location 级指令，作用是在内核层面为匹配到的文件提前发起异步预读，减少磁盘 I/O 延迟。它只对使用 sendfile 传输的文件生效，且仅在 Linux 系统上可用。
- 必须开启
sendfile on，否则read_ahead不起作用 - 语法为
read_ahead size，size 推荐设为1m（1MB）或2m，适合多数静态资源 - 仅在
location块中配置，不支持全局或 server 级别
示例配置：
location ~* \.(js|css|woff2|ttf|mp4)$ {
root /data/static;
sendfile on;
tcp_nopush on;
read_ahead 1m;
}搭配 open_file_cache 提升元数据效率
预读效果依赖于文件是否能快速定位和打开。open_file_cache 缓存文件句柄、大小、修改时间等元数据，避免重复 stat 系统调用，间接增强预读响应速度。
- 设置
open_file_cache max=1000 inactive=60s可缓存常用文件描述符 - 搭配
open_file_cache_valid 60s定期验证缓存有效性 - 建议与
read_ahead同时启用在静态资源 location 中
注意适用场景与限制
预读不是万能加速器，需结合实际资源特征使用：
- 对小文件（如 <4KB 的图标、小 PNG）效果不明显，甚至可能浪费内存带宽
- 对顺序读取的大文件（如视频、打包 JS）收益显著，尤其在机械硬盘或高并发场景
- 不适用于频繁更新的资源——预读内容不会自动失效，需依赖缓存过期或重启 worker
- 不替代 HTTP 缓存头（如
Cache-Control）或 CDN 预热，属于底层 I/O 优化层
验证是否生效
可通过系统级工具确认预读行为：
- 使用
strace -e trace=pread64,readahead -p $(pgrep nginx)观察 worker 进程是否调用readahead()系统调用 - 对比开启/关闭
read_ahead后，首次请求大文件的time to first byte (TTFB)变化 - 检查
nginx -t确保配置语法正确，该指令在旧版 Nginx（如 <1.17.3）中不可用
