Nginx静态资源缓存回退需依赖版本化路径与文件名：构建时生成带哈希的文件名（如app.a81c2f.js）确保URL随内容变更；Nginx按版本目录（如/v1.5.1-20260715/）精确匹配location并统一设长缓存；HTML必须短缓存或禁用强缓存，避免引用错配；回滚后验证响应头、状态码及ETag是否匹配旧版本。
静态资源缓存本身不“回退”，真正需要回退的是缓存策略所依赖的资源路径和配置逻辑。关键在于让旧版本资源能被浏览器正确识别、加载并复用已有缓存，同时避免新旧策略冲突导致缓存失效或错乱。
用带版本号的文件名锁定缓存生命周期
构建时生成带哈希或时间戳的文件名（如 app.a81c2f.js、main.72bd91.css），确保内容变更即路径变更。这样：
- 旧版本资源在服务器上保留不动，URL 不变，浏览器仍可命中原有缓存
- 回滚时只需切换 Nginx 的 root 指向旧构建目录（如 /var/www/app/v1.5.1-20260715/），所有静态资源 URL 自动对应旧文件
- 无需修改缓存头，因为每个文件名天然绑定唯一内容和缓存周期
配置中按路径区分缓存策略，而非全局统一设置
不要对所有 .js/.css 一视同仁，而是按版本目录做 location 精确匹配：
- 为当前活跃版本（如 /v1.5.2-*）启用长缓存：expires 1y;
- 为历史版本目录（如 /v1.5.1-*）也保持相同缓存规则，保证一致性
- 避免用泛匹配 location ~* \.(js|css)$ 覆盖所有版本，否则回滚后新策略可能误作用于旧路径
HTML 文件必须短缓存或禁用强缓存
HTML 是缓存链路的入口，它决定浏览器加载哪个版本的 JS/CSS。回滚能否生效，取决于用户是否拿到新版 HTML：
- 始终设置 expires -1; 或 Cache-Control: no-cache, must-revalidate
- 确保每次发布都更新 HTML 中引用的资源路径（含版本号），且该 HTML 本身不被长期缓存
- 否则即使服务器已切回旧版，用户仍用着缓存的旧 HTML，继续请求新版本资源，造成错配
验证回滚后缓存是否真实生效
上线后立刻检查三处响应头和行为：
- 打开开发者工具 Network 面板，刷新页面，查看 CSS/JS 请求的 Cache-Control 和 Expires 是否与预期版本一致
- 确认响应状态码是 200 (from disk cache) 或 304 Not Modified，而非每次都 200 OK
- 对比回滚前后同一资源的 ETag 或 Last-Modified，应与旧版本文件一致
