nginx缓存调优核心是精准控制生命周期与绕过逻辑：对no-cache等响应头、/api/v2/等路径、带登录cookie请求强制不缓存；用build_version注入cache_key实现html版本隔离；按状态码分层设置缓存时间；配合purge清理与x-cache-status监控兜底。
高频发布场景下，Nginx 缓存调优的核心不是“缓存越多越好”，而是让缓存既不拖慢更新节奏，也不反复穿透后端——关键在于精准控制缓存生命周期与绕过逻辑。
明确哪些内容必须跳过缓存
发布频繁的资源（如 HTML 页面、API 响应、带版本号的 JS/CSS）一旦被错误缓存，用户就会看到旧内容。不能靠“等过期”来解决，得从源头拦截：
- 对含 no-cache、private 或 Cache-Control: no-store 响应头的响应，强制不缓存：用 proxy_no_cache $upstream_http_cache_control 配合判断
- 匹配 URL 路径，例如所有 /api/v2/ 或 /admin/ 开头的请求，直接 bypass：proxy_no_cache 1;
- 检查 Cookie：登录态用户（含 session_id 或 auth_token）的请求默认不进缓存：proxy_no_cache $cookie_session_id $cookie_auth_token;
用缓存键（cache_key）隔离不同发布版本
静态资源常通过文件哈希命名（如 main.a1b2c3.js），但 HTML 页面往往无此机制。此时可将发布标识注入缓存键：
- 在构建阶段生成一个全局版本号（如 BUILD_VERSION=20260508-1422），写入 Nginx 配置或环境变量
- 定义缓存键时加入该变量：proxy_cache_key "$scheme$request_method$host$request_uri $http_accept_language $BUILD_VERSION";
- 每次发布只需更新版本号，旧缓存自动失效，无需清理磁盘
设置分层缓存时间，兼顾命中率与新鲜度
对同一类资源，不同状态码、不同用户群体、不同访问路径应有差异化缓存策略：
- 200/304 响应：静态资源缓存 24 小时，HTML 页面缓存 5 分钟（proxy_cache_valid 200 304 5m;）
- 404 响应：缓存 1 分钟即可，避免重复回源查不存在的路径
- 对带查询参数的请求（如 ?v=20260508），可启用 proxy_cache_key 包含 $args，但注意防止缓存爆炸
- 用 proxy_cache_use_stale updating，让 Nginx 在后台异步刷新缓存时，仍可返回旧内容，避免用户等待
主动清理 + 监控兜底
再精细的规则也无法覆盖所有发布变更场景，需配套快速响应机制：
- 部署脚本中增加一条命令，触发指定路径缓存清除：curl -X PURGE "https://example.com/static/css/"（需配置 location ~ /purge(/.*)? 和 allow 白名单）
- 在响应头中始终输出 X-Cache-Status（HIT/MISS/EXPIRED/BYPASS），结合日志分析真实缓存效率
- 监控 proxy_cache_miss 率突增——可能是新发布未适配缓存规则，也可能是上游返回了禁止缓存的头
