Nginx 边缘缓存预热：利用脚本实现静态资源的提前推送回源-Nginx-PHP中文网

静态资源缓存预热是通过脚本主动拉取关键文件至Nginx边缘节点缓存，避免首屏缓存未命中；重点预热高流量HTML、核心CSS/JS、关键图片及稳定API响应，并需匹配Nginx缓存配置与发布流程集成。

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>

说明：
- -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，便于追溯