预缓存是由运维或发布流程主动触发、提前将指定资源写入nginx代理缓存区的过程；需明确目标资源、控制写入时机、确保cache_key一致，并通过专用location和自动化流程实现。
预缓存（pre-caching）不是浏览器自动行为，也不是 Nginx 内置的“主动拉取”功能；它本质是**由运维或发布流程主动触发、提前将指定资源写入 Nginx 代理缓存区的过程**。要支持针对特定流量的预缓存优化，关键在于：明确目标资源、控制缓存写入时机、确保缓存键与真实请求一致，并避免干扰正常业务逻辑。
明确哪些资源适合预缓存
预缓存只对具备以下特征的资源有效：
-
高确定性内容：如大版本安装包（
/download/app-v3.2.0.tar.gz）、静态文档（/docs/manual-zh.pdf）、热门活动页 HTML（/campaign/summer2026/index.html） - 高访问预期但冷启动明显：新版本上线前 5 分钟、大促开始前 1 小时、批量邮件推送前
-
响应体稳定、无用户态差异：不依赖 Cookie、Authorization、个性化参数；否则需在
proxy_cache_key中显式排除或标准化
配置 Nginx 缓存区并开放预热入口
先定义专用缓存区，再通过一个受控路径触发预热请求：
- 在
http块中声明缓存区（注意use_temp_path=off和足够大的max_size）：proxy_cache_path /var/cache/nginx/precache levels=1:2 keys_zone=precache:256m max_size=100g inactive=7d use_temp_path=off; - 新增一个仅限内网或认证访问的
location，用于接收预热请求：location /_precache {<br> allow 127.0.0.1;<br> allow 10.0.0.0/8;<br> deny all;<br> proxy_pass https://backend;<br> proxy_cache precache;<br> proxy_cache_valid 200 304 7d;<br> proxy_cache_use_stale error timeout;<br> add_header X-PreCache "true";<br>} - 该 location 不返回内容给终端用户，只负责“触发一次请求并落盘到 precache 区”，后续真实用户请求命中即可直接 HIT
确保缓存键与线上请求完全一致
预缓存是否生效，90% 取决于 proxy_cache_key 是否匹配。务必检查线上流量的真实请求结构：
- 若线上请求带查询参数（如
?v=abc123），则预热请求也必须带相同参数；或统一用proxy_cache_key "$scheme$request_method$host$uri"排除$args - 若线上使用 CDN，且 CDN 会改写
Host或添加头，Nginx 的proxy_cache_key应基于原始值（例如用$http_host而非$host） - 建议在预热后，用真实 URL 发起一次请求，检查响应头中的
X-Cache-Status: HIT是否出现
自动化预缓存执行方式
预缓存不是手动 curl 一遍就完事，需融入发布流程：
-
CI/CD 集成：构建完成生成新资源后，自动调用
curl -X GET http://localhost/_precache/download/app-v3.2.0.tar.gz - 定时预热：对每日固定时段高峰（如早 9 点），用脚本批量预热 TOP 50 资源列表
- 事件驱动：监听对象存储事件（如 S3 PutObject），触发对应 URL 的预热请求
- 所有预热请求应加
User-Agent: PreCache-Bot/1.0，便于日志识别和限流
