这个坑最近特别多人踩；91网页版 ｜ 关于缓存设置的说法；越往下越离谱？有人说是测试，有人说是回滚

这个坑最近特别多人踩；91网页版 | 关于缓存设置的说法；越往下越离谱？有人说是测试，有人说是回滚

最近 91 网页版出问题的讨论区像开了锅：用户看到的内容前后不一致、页面局部加载出旧资源、有人刷到“怪异版本”，越往下越离谱——有人说这是在做 A/B 测试，有人说是回滚操作惹的祸。把感受撇开，问题的根源往往和缓存有关，但并不是简单地“清缓存就好”。下面把这类坑拆开讲清楚，给出排查与落地修复思路，便于快速定位与收口。

问题为什么看起来“越往下越离谱”

• 多层缓存叠加：现代 Web 有浏览器缓存、Service Worker、CDN（边缘缓存）、反向代理（如 Nginx、Varnish）、应用层缓存，这些缓存策略相互作用时容易出现版本不一致。
• 资源版本化不到位：静态资源如果没有哈希命名（content-hash），缓存没办法安全失效，用户可能继续拿到旧文件。
• Cache-Control 与 ETag/Last-Modified 使用不当：设置了长 TTL 却又在服务端更新内容，会造成边缘缓存与客户端缓存不同步。
• 缓存 key 不一致：包含 Cookie、Header（如 Accept-Language）、Query 参数等都会影响缓存命中，如果这些因素没被考虑，边缘会返回针对其他用户/场景生成的页面。
• 部署/回滚流程松散：回滚或分阶段发布没有处理好静态资源和接口兼容性，导致新旧版本混杂。
• Service Worker 的存在：它可以拦截请求并返回缓存资源，错误的更新策略会让用户持续看到旧版本，且排查不易。

常见误判与谣言（为什么有人说是在“测试”）

• A/B 测试确实会导致不同用户看到不同内容，但 A/B 一般由实验平台或 Feature Flag 控制，且有日志/配置可查。看到混乱但没有实验记录，大概率不是 A/B。
• 回滚会产生短时间不一致，但通常伴随部署日志、CI 的回滚记录。若问题持续并且没有回滚记录，问题更像是缓存未失效或配置错误。
• “浏览器问题”也是常见甩锅对象，确实会有个别浏览器/版本差异，但当大量不同设备同时复现时，问题更可能出在服务器端或 CDN。

排查清单（快速定位要点）

1. 能否复现？

• 用无痕/隐身窗口、不同网络、不同机器尝试。
• 在浏览器 DevTools 里勾选“Disable cache” 后重试，观察是否消失。

1. 查看响应头

• curl -I https://… 检查 Cache-Control、Expires、ETag、Last-Modified、Vary 等。
• 注意 Set-Cookie 或 Authorization 导致缓存变为 private。

1. 检查 CDN / 边缘缓存

• CDN 的命中率、缓存键、最近的刷新记录和配置变更。
• 尝试直接击中源站（绕过 CDN），对比响应。

1. Service Worker

• 在 DevTools > Application 看有没有激活的 Service Worker，以及它的 fetch 策略（network-first、cache-first 等）。

1. 日志与 Trace

• 在请求链路加入请求 ID 或在后端记录客户端 IP、User-Agent、接收时间及返回版本，方便差异化回溯。
• 查看最近的部署/回滚记录、配置变更、CDN 规则变更时间点。

1. 验证资源版本化

• 静态资源（JS/CSS/图片）是否带 hash，资源路径是否一致。

可立即采取的临时救火措施

• 先行清理边缘缓存（CDN purge），并观察是否立刻缓解用户投诉。
• 如果 Service Worker 导致问题，发布一个修正的 SW 或通过响应头让 SW 退场（unregister）。
• 将关键 API 的 Cache-Control 设置为 no-store 或 private，确保动态内容不被缓存到公共层。
• 在客户端显示“已更新，请刷新”的提示并提供强制刷新按钮（Ctrl+F5 或清除缓存）。

长期修复与最佳实践（不要再踩同样的坑）

• 静态资源采用 content-hash 命名：每次构建产生唯一文件名，浏览器与 CDN 可以安全长期缓存（Cache-Control: immutable）。
• 对动态页面/接口按场景设置缓存策略：
• API → short TTL 或 no-store，必要时用 ETag + If-None-Match 组合实现条件请求。
• 公共静态资产 → long TTL + 文件名版本化。
• 明确缓存键与 Vary：如果响应依赖 Cookie、Accept-Language 等，必须在 Vary 中声明，或把这类接口设为 private。
• Service Worker 策略要小心：采用 network-first 或在发布新版本时强制更新缓存，并在 Service Worker 激活时控制好旧缓存的清理。
• 部署与回滚流程要和缓存策略联动：
• 回滚时先把旧资源仍可访问（或把新资源回滚时做兼容），避免因资源缺失导致页面断裂。
• 发布时序：先上新静态文件（chunk 带 hash），再更新页面引用，最后切换服务端逻辑。
• 采用灰度/金丝雀发布代替盲目回滚：如果需要回退，先在小范围内验证并清理缓存，再逐步扩大。
• 建立自动化验证：在 CI/CD 后做一次端到端的缓存校验（访问页面、比对资源版本、检查响应头）。

沟通与监控

• 当问题发生，快速声明当前状况与预估修复时间，避免社区猜测“测试/回滚”的各种版本故事。
• 监控合成事务：不同地区、不同网络环境的请求与返回版本，自动报警。
• 记录用户报错信息与浏览器信息，方便复现并分层定位（客户端、边缘、源站）。

简易应急检查项（可复制到值班小卡片）

• 能否复现？（多设备、多网络）
• curl -I 比对响应头
• CDN 是否命中/有 purge 记录
• Service Worker 是否拦截
• 资源是否带 hash
• 最近有没有部署/回滚/配置变更
• 临时措施：CDN purge → 强制刷新提示 → 把关键接口设为 no-store

结语 这类“越往下越离谱”的情况，看着像谜题，实际上常常是多层缓存和发布流程之间的博弈。把“缓存策略”“部署顺序”“服务端兼容性”这三条理顺了，能够把绝大多数问题扼杀在摇篮里。发生问题时先做可观测的排查、再动手清缓存或回滚，避免一通操作把局面越推越糟。

如果你愿意，可以把你能拿到的响应头（curl -I 的输出）、出现问题的 URL、以及是否用了 Service Worker 发过来，我帮你看一眼，快速指出最可能的罪魁祸首。