多个用户同时反馈——91网 - 91在线 ｜ 关于缓存设置的说法——我把过程完整复盘了一遍？！大家自己判断

多个用户同时反馈——91网 - 91在线 | 关于缓存设置的说法——我把过程完整复盘了一遍？！大家自己判断

最近有好几位用户同时向我反馈了同一类问题：访问 91网（91在线）时，页面、资源加载不稳定，有时内容看起来是“过期”的，有时又是最新的。我把整个排查过程从头到尾复盘给大家：我做了哪些检查、发现了哪些细节、采取了哪几步验证，以及最后给出的可执行建议。结论留给大家自己判断——希望这篇能帮你更快定位和解决类似问题。

一、问题起点：多个用户同时反馈

• 症状：页面内容与编辑后的最新版本不一致；静态资源（JS/CSS/图片）有旧版本残留；刷新或清缓存后偶尔恢复正常。
• 影响范围：多台不同网络的用户同时报告，说明问题可能不是单一客户端缓存问题。
• 背景假设：可能与服务器端缓存、CDN、浏览器缓存策略或服务工作线程（Service Worker）有关。

二、排查思路（我按这几个维度逐步排查）

1. 客户端快速排查

• 命令与工具：Chrome DevTools（Network 面板）、无痕窗口、清缓存强刷新（Ctrl+F5）、curl -I。
• 检查点：是否存在 Service Worker、浏览器缓存是否关闭、是否能通过强刷新拿到最新资源。

1. 服务器与响应头排查

• 检查 HTTP 头：Cache-Control、Expires、ETag、Last-Modified、Vary、Age。
• 比较 origin（源站）与 CDN 返回的响应头，确认两者是否一致。
• 使用 curl -I https://example.com/path 来快速读取响应头，或用 curl -v 查看重定向链。

1. CDN / 代理 / 负载均衡排查

• 是否使用了 CDN（Cloudflare、Akamai、Fastly 等）或反向代理（Nginx、Varnish）？
• 检查 CDN 的缓存规则（缓存路径、忽略 query string、缓存时间、缓存键）。
• 是否出现节点不同步或缓存未被正确清理（purge）？

1. 应用层与构建流程排查

• 是否在发布流程中改变了文件名（版本号、hash）、却在某些地方仍引用旧路径？
• 是否用了 Service Worker 来做离线缓存？如果有，Service Worker 的缓存策略和更新逻辑是否正确？

三、我实际做的操作（逐步复盘）

1. 复现问题

• 在不同网络、不同设备、不同浏览器重复访问问题页面，记录时间点和响应差异。
• 在问题出现时，用 DevTools Network 面板查看资源的状态码、缓存来源（from disk cache / from memory cache / from service worker / from network）。

1. 检查响应头

• 用 curl -I 检查静态资源和 HTML 的响应头，重点查看 Cache-Control 与 ETag。
• 发现部分静态资源在源站返回短缓存（例如 Cache-Control: max-age=60），但 CDN 返回了长期缓存且 Age 值很高，说明 CDN 层缓存策略覆盖了源站期望。

1. 比对 CDN 与源站

• 在不同 CDN 节点（或使用 CDN 提供的调试工具）抓取同一 URL，发现部分节点尚未更新缓存。
• 执行了 CDN 清理（Purge），并观察是否能马上看到更新。

1. 检查 Service Worker

• 确认是否部署了 Service Worker。发现某些旧页面被 Service Worker 拦截并提供缓存版本，更新逻辑没有触发激活。
• 在 DevTools Application → Service Workers 中强制注销后，页面恢复正常，说明 Service Worker 的缓存策略存在问题。

四、关键发现（总结）

• 问题不是单一原因，而是多个层级的缓存策略冲突叠加造成的：

1. 部分静态资源在源站设置了短缓存，但 CDN 配置了较长缓存，未正确遵循源站指令或没有配置缓存键。
2. Service Worker 在部分客户端长期缓存旧版本并未及时更新。
3. 发布流程偶尔没有改变文件名（hash），导致浏览器/中间层缓存无法区分新旧资源。

• 多用户同时反馈的原因：当 CDN 节点之间存在不同步或 Service Worker 没有正确更新时，不同用户会看到不同版本。

五、可执行建议（按优先级）

1. 优先诊断并统一缓存策略

• 源站通过响应头明确指定 Cache-Control（静态资源可用长缓存 + 文件名版本化；HTML 页面可设为短缓存或 no-cache）。
• CDN 配置应尊重源站的 Cache-Control，或在 CDN 端明确配置覆盖规则并与开发团队同步。

1. 强化版本管理（最稳妥）

• 静态资源上线时采用文件名版本化（例如 main.abc123.js），这样能有效避免旧缓存问题。
• 如果无法文件名化，则在引用上加版本参数（query string），但注意 CDN 是否忽略 query string。

1. 审核 Service Worker 更新逻辑

• 确保 Service Worker 在新版本发布时能正确 skipWaiting 和 clients.claim，或者在发现更新时提示用户刷新。
• 在调试阶段，提供临时接口或脚本可清除客户端 Service Worker 缓存。

1. 建立发布后验证流程

• 发布后立即通过若干 CDN 节点和不同网络点位验证资源版本（自动化脚本可运行 curl 对比响应头和文件 hash）。
• 若采用 CDN，集成自动化 purge 或设置合理的缓存失效策略，避免人工清理延迟。

六、如何自己快速核查（给你几个常用命令）

• 查看响应头：curl -I https://yourdomain.com/path
• 查看带详细信息：curl -v https://yourdomain.com/path
• Chrome：打开 DevTools → Network，勾选 Disable cache；观察 Resource 的 Size / Status / Initiator。
• 检查 Service Worker：DevTools → Application → Service Workers。

七、结语：大家自己判断 缓存问题往往藏在多层结构里：浏览器、应用、源站、CDN、Service Worker，都能影响最后用户看到的内容。通过这次复盘，我把可能性一一排除并定位到主要矛盾点：CDN 与客户端缓存策略不一致、以及 Service Worker 更新机制失效。若你也遇到类似现象，可以按照上面步骤快速定位并验证。遇到具体技术细节想讨论，发上响应头、使用的 CDN 名称和 Service Worker 代码片段，我可以继续跟进帮你分析。大家自己判断，欢迎留言交流你的发现。