缓存预热不是加个 proxy_cache_valid 就能自动发生的——Nginx 本身不提供主动拉取、批量加载的内置机制，必须靠外部触发或配置协同实现。
为什么 proxy_cache 不会自动预热
Nginx 的 proxy_cache 是被动缓存：只有真实请求到达并被命中时，才会回源、缓存、再服务。它没有后台线程去“提前抓取”URL，也不会读取 sitemap 或访问日志自动填充。如果你期望首页、商品列表页、API 聚合接口在流量高峰前就已在磁盘就位，就得手动干预。
-
proxy_cache_use_stale updating只解决“正在更新时返回旧缓存”，不解决“还没缓存过”的冷启动问题 -
proxy_cache_lock on防止缓存击穿，但前提是已有缓存；首次请求仍需穿透到后端 - 即使设置了
proxy_cache_valid 200 1h，若没人访问/api/reports，它就永远不会进缓存
三种可行的预热方式及实操要点
真正落地的预热，基本就这三类路径，选哪个取决于你的发布节奏、资源粒度和运维能力：
-
curl + shell 脚本轮询：最轻量，适合固定 URL 列表（如首页、核心频道页）。注意加
-H "Cache-Control: no-cache"避免被本地中间件拦截，用-s -o /dev/null静默执行，避免日志刷屏 -
利用 Nginx 日志 + awk + curl 回放：从
access.log提取高频GET请求（排除 POST/UA 为 crawler 的行），过滤出状态码 200 且无敏感参数的 URL，去重后并发请求。注意加--limit-rate=100K控制带宽，避免压垮后端 -
结合 CI/CD 在部署后自动触发：在 Jenkins/GitLab CI 的 deploy job 末尾加入预热步骤，调用预热脚本。关键点是确保脚本运行时 Nginx 已 reload 且缓存路径可写，建议用
sleep 2 && ./warmup.sh错开 reload 窗口
预热失败的典型现象与排查点
你以为发了请求就进了缓存？常见卡点如下：
- 响应头含
Set-Cookie或Cache-Control: private, no-store→ Nginx 默认跳过缓存，需显式加proxy_ignore_headers Set-Cookie和proxy_cache_valid any 10m - 后端返回
Vary: Cookie, User-Agent→ 缓存 key 变复杂，proxy_cache_key若没包含$http_cookie，会导致大量 MISS；预热请求若没带对应 Cookie，也拿不到有效缓存 - 缓存路径权限不对：
ls -ld /var/cache/nginx必须是www-data:www-data（Ubuntu）或nginx:nginx（CentOS），否则写入失败且无明显错误日志 - 配置未生效：确认预热请求走的是启用了
proxy_cache的location，而不是直连静态文件或 fallback 到其他 server 块
缓存预热不是一劳永逸的事
它本质是“把不确定性前置”。每次配置变更（比如改了 proxy_cache_key）、每次后端接口逻辑调整（比如新增鉴权 header）、甚至每次清理磁盘（rm -rf /var/cache/nginx/*）都会让预热失效。真正的高可用架构里，预热只是辅助手段，proxy_cache_use_stale error timeout updating 和合理的 inactive 时间（别设成 7d）才是应对突发流量的底线保障。
