别怪我直说：我以为91官网没变化，直到我发现缓存管理悄悄变了（这点太容易忽略）
你也许曾经碰到过这种体验：明明刚刚更新了页面或图片，刷新几次却看不到任何变化；以为网站没改，最后发现只是缓存在作怪。缓存并非只有“浏览器没有更新缓存”这么简单——缓存层级多、变化方式也会悄无声息，尤其是当网站、CDN或浏览器的缓存策略被悄悄调整后，更容易让人误以为网站没有变化。下面把我发现问题的流程、排查方法和可落地的解决办法都讲清楚，既适合普通访客，也能帮站长定位并修复缓存相关的坑。
一、缓存会在哪里“悄悄变”
- 浏览器缓存：受 Cache-Control、Expires、ETag、Last-Modified 等响应头控制。浏览器可能会基于这些头长期使用旧资源。
- CDN 缓存：像 Cloudflare、Akamai 等会把资源缓存到边缘节点，清理或规则变更会影响用户看到的是哪一版。
- 服务器端缓存：后端可能启用了缓存层（例如 Varnish、nginx proxy_cache），更新策略改变会导致内容滞后。
- 服务工作线程（Service Worker）：如果有安装 Service Worker，可能拦截并返回缓存资源，行为更“隐蔽”。
- 中间代理或公司网络：公司网络、ISP 代理也可能缓存响应。
二、如何判断是不是缓存问题（快速检测）
- 无痕/隐身窗口：打开隐身窗口访问页面，看是否有变化。
- 强制刷新：在页面上按 Ctrl+F5（Windows）或 Command+Shift+R（Mac）来做无缓存刷新。
- Chrome 开发者工具：打开 DevTools → Network，勾选 Disable cache（只在 DevTools 开着时有效），重新加载页面，观察请求是否命中 200/304 或来自 Service Worker。
- curl 查看响应头：在终端运行 curl -I https://你的域名/资源路径 关注 Cache-Control、Expires、ETag、Age、Via 等头部字段。Age 表示资源已被缓存多久（CDN/代理）。
- 检查 Service Worker：在 DevTools → Application → Service Workers，看看是否有注册并拦截请求。
三、常见“悄悄变了”的场景与对应判断
- 场景：你确认更新了静态资源，但用户仍看到旧文件。 判断：curl -I 得到相同 ETag 和 Last-Modified，或 CDN 的 Age 值很大，说明是缓存未失效。
- 场景：只有部分用户看到新内容，部分看到旧内容。 判断：可能是 CDN 的边缘节点还没清理，或不同地区路由到不同缓存节点。
- 场景：开发者控制台显示 200 表示缓存被强制返回而不是 304。 判断：服务端或者 CDN 返回了缓存的完整副本（可能是配置为缓存所有响应）。
四、站长/开发者应做的（可操作清单）
- 给静态资源做版本管理：在资源 URL 上加入版本号/哈希参数，如 /app.js?v=20260220 或 /styles.ab12cd.css。这样一改名就强制命中新文件。
- 合理设置 Cache-Control：
- 静态、长期不变的资源：Cache-Control: public, max-age=31536000, immutable
- 动态或频繁变更的页面：Cache-Control: no-cache, must-revalidate 或 private, max-age=0
- 使用 ETag/Last-Modified 做条件请求：确保服务器正确响应 If-None-Match/If-Modified-Since，从而让浏览器获取更新。
- CDN 缓存失效策略：通过 API 或管理面板主动 purge/清理缓存；为关键资源设置较短的 TTL 或使用缓存规则来区分静态与动态资源。
- 注意 Service Worker：更新 Service Worker 时要正确处理激活逻辑（skipWaiting/clients.claim）并设计好更新策略，避免用户长期被旧 SW 缓存控制。
- 日志与监控：记录请求头、响应头与缓存命中率，遇到问题能追溯是哪一层出问题。
五、作为普通用户你可以怎么做（几步马上排查）
- 先用隐身模式打开页面，看是否有差异。
- 做强制刷新（Ctrl+F5 / Cmd+Shift+R）。
- 在 Chrome DevTools 的 Network 面板勾选 Disable cache 并刷新。
- 对资源使用 curl -I 查看响应头，关注 Age、Cache-Control、ETag。
- 如果怀疑 Service Worker，去 DevTools → Application → Service Workers，点击 unregister 卸载试试。
六、如果你在使用 Google Sites 发布内容 Google Sites 在服务器端对缓存的控制有限，不能像自己托管那样自由设置响应头。面对缓存问题可以采取以下方法：
- 修改资源名或在嵌入资源的 URL 加上版本参数来“逼迫”浏览器拉取最新内容。
- 每次更新后在 Sites 中重新发布（有时 republish 会刷新 Google 的缓存）。
- 若嵌入第三方资源，尽量让这些资源托管在可控的 CDN/服务器上，便于设置合适的缓存策略。
- 向用户说明清理浏览器缓存或使用隐身窗口查看最新内容，减少误会。
七、实战小结（快速排查顺序）
- 尝试隐身/强制刷新。
- 打开 DevTools 看请求与响应头，是否有 Cache-Control、Age、ETag 等。
- 用 curl -I 确认服务器端返回的头部信息。
- 检查是否有 Service Worker 拦截请求。
- 如为站长，考虑版本化资源与 purge CDN。
结语 缓存是加速体验的好帮手，但有时也是“让人以为网站没变”的罪魁祸首。遇到“网站没更新”的尴尬，别急着归咎内容本身，先按上面清单逐层排查：浏览器、Service Worker、CDN、服务器端。问题找到后，用版本控制、合理的 Cache-Control 与主动的缓存清理策略，就能把这些隐形的问题消灭在萌芽里。
