有人在群里丢来一张截图，断言“91官网的缓存设置完全乱套了”，评论区瞬间炸开了锅：有人说真的是网站问题，有人说是自己浏览器作怪，还有人搬出了“CDN+缓存策略”的专业词儿。为了弄清楚到底发生了什么，我把整个过程完整复盘了一遍——把我查到的事实、复现步骤、分析结论和可执行建议整理在下面，方便网站管理员和普通用户都能看懂并处理类似情况。
事情起点
- 收到的那张截图展示了网页响应头的部分字段（主要是 Cache-Control、Expires、Set-Cookie、Age、Via、ETag 等），以及页面在不同时间点显示不一致的证据。截图没有给出完整上下文（例如访问时间、是否处于登录状态、是否经过 CDN 控制台设置），所以需要复现并补齐信息。
- 评论区分成两派：一派说“服务器没设置好，缓存缓存成灾”；另一派说“你清一下浏览器缓存就好了”。显然要把两类可能性都排查一遍。
复盘与复现步骤（我做了什么）
- 收集上下文
- 记录截图中的 URL、时间戳、是否带有查询参数（?v=xxx）、是否登录状态、是否有 Cookie 提示。
- 把截图里的响应头抄出来，作为初步线索。
- 本地浏览器复现（Chrome DevTools）
- 打开 Network，勾选 Disable cache，然后访问页面，观察首次请求与刷新后的差异。
- 观察 HTML 与静态资源（JS/CSS/图片）的响应头，注意 Cache-Control、Expires、ETag、Last-Modified、Set-Cookie、Vary。
- 做两次对比：普通刷新 (F5) 与强制刷新 (Ctrl+F5 / Shift+F5)。
- 命令行复现（curl）
- 基本请求头查看：curl -I "https://example.com/path"
- 模拟无缓存请求：curl -I -H "Cache-Control: no-cache" "https://…"
- 模拟带 Cookie / 不带 Cookie 的差异：curl -I -b "name=value" 以及不带 cookie。
- 跟随重定向：curl -I -L "https://…"
- CDN / 中间层验证
- 观察 Via、X-Cache、Age 这些头，判断响应是否来自 CDN 缓存以及缓存年龄。
- 如果网站使用 Cloudflare、Fastly、阿里云 CDN 等，检查是否有 Surrogate-Control 或者 CDN 控制台的页面规则导致差异。
- 多设备/多网络验证
- 用手机数据网络、公司内网、VPN 等分别访问，看看是否存在地域或节点差异。
- 使用隐身模式或清完 Cookie 的窗口再试一次，排除本地 Cookie 导致的行为差异。
关键发现（基于我复验得到的数据）
- HTML 页面和静态资源的缓存策略明显不同：
- 静态资源（如 js、css、图片）通常设置了较长的 Cache-Control: max-age=31536000 或者使用带版本号的 URL，因此缓存行为稳定。
- HTML 页面返回了 Set-Cookie 或带有 Vary: Cookie，导致 CDN/代理默认不会缓存该响应，或只缓存了特定变体。
- 出现“看到旧内容”的直接原因通常是：某些节点（CDN 边缘）仍然持有旧版本的 HTML，而源站在更新时没有完整触发缓存清除（purge），或者 purge 规则仅针对部分路径/文件。
- 在某些请求里响应头包含 Age 与 X-Cache: HIT，说明确实是缓存命中；另一些请求显示 X-Cache: MISS 或来自源站，显示出的内容会不同。
- 个别情况下，浏览器的本地缓存（特别是带有强缓存策略的静态资源）会掩盖 HTML 的更新差异，给用户造成“页面没更新”的错觉。
为什么评论区会吵翻
- 大部分人只看到了页面表现（看到了旧内容或新内容），缺少对响应头与 CDN 行为的理解，所以把问题归结为“浏览器缓存”或“服务器问题”。
- 截图提供的信息不完整（如缺少 Age、X-Cache、完整的 Set-Cookie），导致各自凭经验下结论，越说越偏离事实。
- 站点在不同时间、不同节点上出现不一致，本身就是容易引发争议的触发点——有的人恰好命中了已更新的节点，有的人命中未更新的边缘节点。
给站点管理员的可执行建议（按优先级）
- 避免在公共页面上返回 Set-Cookie，除非确实需要。Set-Cookie 会导致一些 CDN/代理将响应视为个性化，从而不缓存或仅作为私有内容处理。
- 明确 HTML 与静态资源的缓存策略：HTML 一般设短 TTL（例如 0 或 60 秒）并使用 Surrogate-Control / Edge-Control 给 CDN 单独的缓存指令；静态资源通过版本化（hash）和长 TTL 保持高缓存命中率。
- 配置 CDN 的缓存规则：
- 对于需要缓存的页面设置合适的缓存策略并在发布时执行 purge（或使用缓存分层策略与软/硬失效机制）。
- 如果页面根据 Cookie 或 Authorization 展示不同内容，考虑在服务器端或 CDN 侧分离公共内容与个性化内容（edge side includes、fragment caching）。
- 增量发布与缓存清理：
- 部署流程中加入缓存清理（按路径或 tag 清理），避免单次更新后多节点不同步的情况。
- 使用版本号策略，更新关键静态资源时直接换 URL，以避免依赖即时 purge。
- 在响应头中体现清晰的缓存指令，避免混杂相互矛盾的字段（比如同时给出 Cache-Control: no-cache 和 Expires 为将来时间会引起混淆）。
给普通用户的快速应对方法
- 遇到页面显示异常，先尝试强制刷新（Ctrl/Shift + F5 或清缓存并重启浏览器），或打开隐身窗口再访问。
- 在地址后加一个短时间戳参数（?t=12345）临时绕过缓存，确认问题是否为缓存引起。
- 尝试不同网络或设备，判断是否为 CDN 节点差异导致的问题。
- 如果你愿意，可以把浏览器 Network 的完整请求头/响应头截图发给网站管理员，这些信息能快速定位问题。
我的结论（简明）
- 单凭一张截图很难给出最终责任方；复现和多点验证能快速缩小问题范围。
- 多数类似争议的根源在于：一边是正确配置了静态资源缓存，另一边 HTML 与个性化响应的缓存策略没管好，导致不同节点或不同用户看到不同结果。
- 通过合理的 CDN 规则、清晰的响应头和发布时的缓存刷新，可以在绝大多数情况下避免“看到旧页面/部分用户看到新页面”的尴尬。
