Nginx 无原生静态资源预热功能，但可通过 open_file_cache 缓存元信息、脚本主动请求触发内容加载、proxy_cache 预存压缩响应及 sendfile/TCP 优化协同实现高效预热。
Nginx 本身不提供原生的“静态资源预热”功能，但可通过组合缓存机制、文件系统优化与主动触发策略，在首次真实请求前完成关键静态资源的加载、解压与内存驻留，从而显著降低首访延迟（TTFB 和 FCP）。核心目标是让 Nginx 在用户发起请求前，就把热门文件准备好——不是靠猜，而是靠可控的预加载。
提前加载并缓存静态文件到内存
Nginx 的 open_file_cache 是实现轻量级“预热”的关键。它不预读文件内容，但会缓存文件元信息（如 inode、大小、修改时间）和打开句柄，大幅减少首次访问时的 open()、stat() 系统调用开销。
- 在
http{}块中启用并调优：
open_file_cache max=2000 inactive=60s;
open_file_cache_valid 120s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
- max=2000：限制缓存条目上限，避免内存溢出
- inactive=60s：60 秒内未被访问的条目会被淘汰
- min_uses=2：一个文件需被至少访问两次才进入长效缓存（过滤偶然请求）
- 配合
open_file_cache_errors on，可缓存不存在文件的 negative 结果，避免反复查错路径
该机制虽非严格意义的“内容预热”，但在高并发首屏场景下，能将文件元数据查找耗时从毫秒级降至微秒级，对 index.html、main.css、vendor.js 等关键入口文件效果明显。
用脚本主动触发关键资源缓存
真正实现“预热”，需在部署后或流量高峰前，用 curl 或 wget 主动请求一批核心静态资源，强制 Nginx 完成：
→ 文件读取
→ Brotli/Gzip 压缩（若启用）
→ 缓存写入（proxy_cache 或本地磁盘缓存）
→ open_file_cache 条目建立
- 示例预热脚本（bash）：
for url in /index.html /static/css/app.css /static/js/chunk-vendors.js; do
curl -s -o /dev/null -H "Accept-Encoding: br" https://yoursite.com$url
done
- 建议在 CI/CD 流程末尾或凌晨低峰期执行
- 搭配
proxy_cache_use_stale updating可进一步保障预热期间用户请求不降级
结合 proxy_cache 预生成压缩后响应
若你使用 Nginx 作为反向代理（例如后端是 Node.js 或 Python 应用），可配置 proxy_cache 实现真正的响应体预热：
- 定义缓存区：
proxy_cache_path /var/cache/nginx/static levels=1:2 keys_zone=static:100m max_size=2g inactive=7d use_temp_path=off; - 在 location 中启用：
proxy_cache static; proxy_cache_valid 200 302 1y; - 预热时请求资源，Nginx 就会把已压缩（Brotli）、带完整响应头的内容存入磁盘缓存
- 后续用户请求命中缓存，直接返回，跳过所有后端逻辑与实时压缩
这种方式对 SSR 页面、API 返回的 JSON 等同样有效，且支持按状态码、header 精细控制缓存行为。
补充：利用 sendfile + TCP 优化加速传输路径
预热只是准备就绪，真正快还得靠高效交付：
- 确保
sendfile on;：绕过用户态拷贝，内核直接 DMA 传输文件 - 启用
tcp_nopush on;：配合 sendfile，等缓冲区满再发包，减少小包数量 - 开启
tcp_nodelay on;：对非 sendfile 场景（如动态内容）降低延迟 - 若使用 HTTP/2，多个资源复用单连接，预热后的首屏资源可并行推送（
http2_push）
这些参数不改变预热逻辑，但决定了预热成果能否被用户快速感知。
