有网友翻出旧版对比；91网页版 - 91在线：关于缓存设置的说法；这次终于说清楚！有人说是测试，有人说是回滚
近期有用户把新版和旧版页面截图、响应头、加载速度拿出来对比，引发了一波关于“缓存设置变化”的讨论：有说法称这是一次测试（A/B、分阶段发布），也有人断言这是回滚操作导致的旧配置回归。把技术细节和用户能马上验证的办法梳理一下，帮助普通用户和站方快速判断到底发生了什么，以及接下来该做什么。
一、现象汇总——大家看到了什么
- 页面加载表现不一：有的用户打开的是旧资源（旧图标、旧样式），有的看到的是已更新的资源。
- 响应头有差异：部分用户截到的 Cache-Control、ETag、Age、Last-Modified 或者服务端版本号不同。
- 部分资源更新滞后：静态资源像 CSS/JS、图片等在某些节点上被长期缓存。
- 社区讨论里出现两个猜测：A/B 测试（或灰度发布）和回滚（撤回新版、恢复旧配置）。
二、可能的技术原因（从最常见到较少见）
- 分阶段发布/灰度（A/B）： 站方对小部分用户下发旧版或新版，以监测指标或逐步放量。不同用户看到不同缓存策略很常见：一些边缘节点仍在推旧配置。
- CDN 缓存策略差异： CDN 节点和回源策略不同会导致某些边缘节点继续返回旧缓存，直到 TTL 到期或被主动清理。
- 回滚操作： 如果部署出现问题，运维可能回滚至旧版本，同时恢复旧的缓存头或资源路径，用户可能立即感到“回到旧版”。
- 配置误改或不同环境同步问题： 新配置未完全下发到所有服务器或配置中心不同步，会出现不一致。
- Service Worker 或浏览器缓存： 客户端的 service worker 或浏览器强缓存（缓存策略、离线缓存）会导致少数用户看到旧资源，尤其在 Progressive Web App 场景下更明显。
- 缓存键/指纹（cache-busting）策略失效： 如果静态资源没有按版本指纹命名，或构建流程未更新版本号，缓存会造成资源难以及时更新。
三、普通用户能做的快速验证步骤
- 在浏览器按 F12 → Network，勾选 Disable cache，然后刷新，看是否加载到新版资源。
- 用 curl 查看响应头：curl -I https://example.com/page 重点看 Cache-Control、Age、ETag、Last-Modified、Server、Via、X-Cache 等字段。
- 用无痕/隐私窗口或换个网络（移动数据）试试，判断是不是 CDN 边缘节点差异或本地缓存问题。
- 检查 service worker：Application → Service Workers，看是否有启用且拦截了请求，必要时卸载或更新它。
四、站方（开发/运维）可以如何快速排查与补救
- 检查发布流程与回滚记录：查看是否有回滚操作、部署日志、发布开关、Feature Flag 的变更记录。
- 查看 CDN 状态与缓存清理日志：是否有分区 purge、是否对所有 POP 做了刷新，TTL 是否设置合理。
- 检查响应头策略：
- HTML 页面宜设置短 TTL 或 no-cache，让浏览器/中间层尽快回源获取新版本。
- 静态资源（带指纹）可设置长缓存（Cache-Control: public, max-age=31536000, immutable）。
- 确保 ETag 与 Last-Modified 正确反映资源变化。
- 检查和管理 Service Worker：若启用了 SW，发布新版本时需要更新缓存逻辑和版本号，做好激活与清理流程。
- 实施灰度与回滚的可观察性：发布时开启分段状态监控，记录流量路由、错误率与缓存命中率，便于回滚时判断影响面。
- 使用版本化资源路径或指纹（hash）确保静态资源变更能被客户端识别并强制刷新。
五、如何判断“是测试还是回滚”——实用线索
- 日志与发布记录：确凿证据，查看是否确实触发了回滚命令或灰度规则变更。
- 时间点与范围：回滚通常是一次性的、覆盖较大流量；灰度则表现为长期并存、流量按比例分流。
- 响应头与 cache-control 的差异：回滚通常会把整个系统回到旧配置，response header、版本号一致性更强；灰度会出现并存的 header 组合。
- 社区/官方通告：若站方遇到可见问题，一般会在渠道发布说明，监测这些通告也能给出答案。
六、小结与建议 目前从用户反馈和常见运维行为看，既可能是分阶段的测试/灰度发布导致不同用户看到不同缓存行为，也可能是回滚或 CDN 同步问题。对普通用户，先做本地排查（F12、无痕、curl）；对站方，优先核对发布/回滚日志、CDN 缓存和 Service Worker 配置，并在发现影响面时及时通知用户、并结合指纹与缓存策略减少类似情况发生。