群里突然炸了 - 91网页版 - 关于缓存设置的说法：细节多到我怀疑人生？！现在的问题是：到底哪里变了

前言 最近群里一阵哗然：用户看到旧资源、页面加载错乱、上线改了半天也不见效——大家把矛头指向“缓存”。缓存确实是个细节多到让人怀疑人生的东西，但通常问题并不神秘：哪里变了，就看哪个环节的缓存策略或行为发生了变化。下面把排查思路、常见原因和可执行修复列出来，方便你在短时间内把“炸锅”场面变回“稳如老狗”。

一、先看症状（这决定你该怎么排查）

• 所有用户都看到旧页面/旧静态资源：可能是CDN或浏览器缓存长期缓存资源。
• 部分用户看到旧内容，部分用户是新内容：可能是CDN边缘缓存差异、区域缓存、或Service Worker差异。
• 刷新（Ctrl+F5）或清缓存能解决问题：说明是缓存层没失效。
• 只有登录用户出现问题：可能Cookie或认证头影响缓存（Vary: Cookie / Authorization）。
• 资源加载 404/500 或是 JS 报错版本不一致：可能是文件指紋（hash）没生成或引用错误。

二、从哪里开始排查（快速、有效） 1) 重现并收集证据

• 用浏览器 DevTools（Network 面板）观察请求和响应头：Cache-Control、Expires、ETag、Last-Modified、Age、Vary、Via、X-Cache 等。
• 在 DevTools 的 Application → Service Workers 查看是否注册了 SW，以及 SW 的 fetch 策略。
• 用 curl -I 检查响应头（便于对比不同节点）： curl -I https://your.site/path/file.js
• 如果怀疑是 CDN，直接抓边缘节点和 origin 的头，或用 CDN 的诊断工具查看缓存命中率和配置。

2) 对比“改前”和“改后”的返回头

• 查最近一次部署改动、CI/CD 配置、Nginx/Apache/Traefik 配置、CDN 配置、或前端打包（是否去掉了 fingerprint）等变更日志。

三、常见“到底哪里变了”的原因（按概率排序）

• CDN 策略变更或缓存未被清理：上线后没有触发 CDN purge，或者 CDN策略把静态文件长期缓存。
• 静态资源不再带内容哈希（fingerprint）：文件名不变则缓存不会失效。
• 服务端/代理（Nginx、CDN）改变了 Cache-Control/Expires 头：例如把 max-age 设大了、或误加入 immutable。
• 新增或修改了 Service Worker（SW）：SW 的缓存策略会让浏览器绕过网络请求，造成部分用户长期使用老版本。
• 添加了导致非缓存的 Vary 头（Vary: Cookie / User-Agent）：缓存分片，某些请求命中旧缓存。
• 加了认证头或 Set-Cookie：含 Authorization 或 Cookie 的响应通常无法被中间缓存，或导致缓存行为异常。
• ETag/Last-Modified 行为不一致：如果 ETag 未变化但内容变了，会命中旧缓存。
• 代理/负载均衡（如 Cloudflare、Fastly）升级或规则变动：可能自动加了安全策略修改缓存策略。
• 前端构建漏掉了产出（例如 hash 生成逻辑出错），导致 index.html 引用旧资源。

四、典型响应头解释（看懂就能判断问题）

• Cache-Control: public, max-age=31536000, immutable
• 表示长期可缓存，适合带哈希的静态资源。
• Cache-Control: no-cache, must-revalidate
• 浏览器每次会向服务器验证（If-None-Match / If-Modified-Since）。
• Cache-Control: no-store
• 不缓存，适合敏感数据或 API。
• ETag / Last-Modified
• 用于条件 GET，如果服务器响应 304，则说明内容未变。
• Vary: Cookie / Authorization
• 缓存会按 Cookie/Authorization 切分，极易造成缓存混乱。
• Age / Via / X-Cache
• 查看是否是 CDN 或缓存节点命中，以及缓存已存在多久。

五、常见修复与最佳实践（可直接落地） 1) 静态资源（JS/CSS/图片）

• 使用内容哈希的文件名（例如 app.abc123.js），并设置长期缓存： Cache-Control: public, max-age=31536000, immutable
• 在 HTML（或 index.html）中引用带哈希的资源。不要依赖 query-string 来做主要的版本控制（某些 CDN 默认不缓存带 query 的 URL）。

2) HTML 页面（比如 index.html）

• 不要长期缓存 index.html：使用短缓存或 no-cache，让浏览器每次向服务器确认： Cache-Control: no-cache, must-revalidate
• 或者用 CDN Edge 的 stale-while-revalidate 策略，保证用户几乎没有等待，同时让边缘尽快更新。

3) API 接口

• 对动态数据使用 no-store 或短缓存，并配合 ETag/Last-Modified 验证： Cache-Control: private, max-age=0, no-cache, must-revalidate
• 对于可缓存的接口，明确设置 Vary，不要无脑加 Vary: *。

4) Service Worker 策略

• 如果使用 SW，确定 SW 更新逻辑：新部署应触发 SW skipWaiting + clients.claim，或者在激活阶段强制清旧缓存。
• 推荐策略：HTML 用 network-first，静态资源用 cache-first（带版本或 hash），并在部署时更新缓存名称以强制清理旧缓存。

5) CDN 与缓存清除

• 上线时，使用自动化脚本触发 CDN purge（针对不带 hash 的资源）。
• 更稳妥的是依赖文件指纹 + 长缓存，而非频繁 purge。

六、快速排查清单（10 分钟内）

• 浏览器：打开 DevTools → Network → 勾选 Disable cache → 访问页面，观察是否恢复。
• DevTools → Application → Service Workers：若有注册，右上角 unregister 并刷新页面验证。
• curl -I 对比 origin 与 CDN 的头，找 Age、X-Cache、Cache-Control 异常： curl -I https://your.site/index.html curl -I https://cdn.edge/your/static/app.js
• 在服务器端查看上次部署日志、Nginx/Caddy 配置、CI 配置是否改了 cache header 或去掉了 fingerprint。
• 检查是否在 HTML 或 meta 标签中插入了 no-cache、pragma 或某些误导性的标签。

七、实战案例（快速示范） 情境：上线后用户仍看到旧 JS，刷新无效，只有部分用户异常。 排查结论很可能是：Service Worker 缓存了旧资源，且 SW 激活策略没有正确更新。 解决办法：

• 发布新版本时在 build 脚本里更新 cache 名称（cache-v2）。
• 在新 SW 的 install 事件完成后调用 self.skipWaiting()，在 activate 阶段清理旧缓存并 clients.claim()。
• 上线后在短时间内观察错误率并准备回滚或强制清 SW。

八、长效建议（避免下次炸群）

• 强制前端资源走文件指纹 + 长缓存策略，HTML / API 用短缓存或验证式缓存。
• 对 Service Worker 流程做规范：每次发布必须伴随 SW 版本变更并确保更新策略可靠。
• CI/CD 打包上线时自动触发 CDN purge（只针对需要即时失效的资源）。
• 监控与告警：部署后自动检测关键资源版本是否为最新（Hash 校验），并在异常时告警。
• 建立“缓存变更”发布通告：任何修改缓存相关配置都要在群/文档里说明，减少“群里炸了”的戏码。

结语 缓存看似细枝末节，但一旦某个环节变了，影响通常放大到全站用户。把问题拆成：谁发了不同的头？哪个缓存层命中了旧资源？是否有 SW 干预？按上面的排查与修复步骤来做，基本上能把“到底哪里变了”的谜团拆开并解决。下次上线，把指纹 + 合理的 Cache-Control + SW 更新策略当作标配，就能把群里的炸锅戏码降到最低。

若你愿意，我可以根据你的站点给出更具体的 header 配置样例、SW 更新模板，或一份 CI/CD 上线时的自动化 purge 脚本。哪一个先来？

本文标签： # 群里 # 突然 # 网页