静态资源缓存预热是通过脚本主动拉取关键文件至Nginx边缘节点缓存，避免首屏缓存未命中；重点预热高流量HTML、核心CSS/JS、关键图片及稳定API响应，并需匹配Nginx缓存配置与发布流程集成。
静态资源缓存预热，本质是让 Nginx 边缘节点在用户访问前就主动拉取并缓存关键文件，避免首屏“缓存未命中”导致的回源延迟。这不依赖用户触发，而是通过脚本模拟请求，把资源“推”进本地缓存（实际是“拉取并缓存”，业内习惯称“预热”）。
明确预热目标：哪些资源值得提前缓存？
不是所有静态资源都需要预热，重点应放在：
- 首页、活动页、商品详情页等高流量 HTML 页面（注意：需确保它们可被合理缓存，例如禁用 Set-Cookie 或分离动态部分）
- 核心 CSS、JS、字体文件（尤其是体积大、复用率高的）
- 关键图片（如 banner 图、Logo，建议 WebP 格式 + 合理压缩）
- 不频繁更新但访问量大的 API 响应（如地区列表、配置 JSON，需配合 Cache-Control: public, max-age=3600）
编写轻量预热脚本：用 curl + 并发控制最实用
无需复杂框架，一个 Bash 脚本即可完成。关键是加 -s -o /dev/null -w "%{http_code}\n" 静默执行并校验状态码，再用 xargs -P 控制并发数防压垮源站：
#!/bin/bash
# preload.sh —— 支持 HTTP/HTTPS，自动跳过 4xx/5xx
URLS=(
"https://example.com/"
"https://example.com/static/css/app.css"
"https://example.com/static/js/vendor.js"
"https://example.com/images/banner.webp"
)
<p>for url in "${URLS[@]}"; do
echo "预热: $url"
done | xargs -I{} -P 5 sh -c 'curl -s -o /dev/null -w "%{http_code} {}\n" -f -m 10 "{}" 2>/dev/null' \
| awk '$1 == "200" {print "✓", $2} $1 != "200" {print "✗", $2, "(", $1, ")"}'
说明：
- -P 5 表示最多 5 个并发请求，可根据源站承受力调整
- -m 10 设置单次请求超时为 10 秒，避免卡死
- -f 让 curl 在非 2xx/3xx 时返回错误码，配合 2>/dev/null 过滤报错信息
- 输出带符号标识，便于快速识别成功/失败项
集成到发布流程：让预热成为上线必经步骤
预热不能靠人工执行，必须嵌入 CI/CD 或部署脚本中：
- 在源站构建完成、新版本已上线后，立即执行
./preload.sh - 若使用 Ansible，可用
uri模块批量调用，支持分组（如先热 CDN 节点，再热边缘 Nginx） - 配合健康检查：预热后用
curl -I验证响应头是否含X-Cache: HIT（需 Nginx 配置add_header X-Cache $upstream_cache_status;） - 记录日志：将预热结果写入
/var/log/nginx/preload-$(date +%F).log，便于追溯
Nginx 缓存配置要点：确保预热真正生效
脚本再好，Nginx 配置不匹配也白搭。关键几项必须检查：
- 启用 proxy_cache_path，并分配足够磁盘空间与 inactive 时间（例如
inactive=1d，避免冷资源长期占位） - location 中必须有
proxy_cache_valid 200 302 1h;，否则即使预热成功，Nginx 也可能不缓存响应 - 对 HTML 文件，建议显式设置
proxy_cache_valid 200 302 10m;（短周期），避免缓存过期内容 - 确认没有全局
proxy_cache_bypass $cookie_nocache $arg_nocache;等规则意外绕过缓存
