有网友翻出旧版对比，91在线——关于缓存设置的说法，关键点居然在这里？有新情况我会继续补
最近一条对比帖把“旧版”和“新版”91在线的页面抓图、资源请求和响应头都翻出来了，讨论焦点很快聚集在“缓存设置到底有没有改？”上。细看这些对比，表面差异很多，真正影响体验和版本一致性的关键点往往不是视觉差异，而是缓存策略与部署流程的微妙变化。下面把能直接看、能动手检验、也能立刻着手优化的几个关键点整理出来，便于站长和普通用户快速判断与应对。
一、从响应头找线索（最直接） 观察点：Cache-Control、Expires、ETag、Last-Modified、Vary、Set-Cookie、Service-Worker。 如何看：在浏览器按F12的Network面板，刷新一次（普通刷新和强制刷新都试试），或用 curl -I URL 获取响应头。 常见现象与含义：
- HTML 返回 no-cache 或 max-age=0：说明服务端想让浏览器每次都做条件请求（比较安全，能保证更新及时）。
- 静态资源有长缓存（max-age 很大）并且文件名不带 hash：可能导致更新后用户仍看到旧资源。
- ETag/Last-Modified 存在但服务端未正确实现 304：说明条件请求机制没配好。 关键点：新版和旧版对比中，差别常集中在静态资源是否采用了 cache-busting（哈希命名）与 HTML 是否被设置为短缓存或 no-cache。
二、部署与 CDN 流程的影响 如果有 CDN 或边缘缓存，页面更新往往还要考虑：
- 是否在每次部署后立即 purge（清理）CDN 缓存；
- CDN 缓存规则是否按 URL 参数、Cookie、请求头区分（Vary）。 关键点：即便后端文件变了，CDN 未清理或规则不当也会把老资源继续返回。
三、Service Worker 和离线缓存 单页应用或带离线能力的页面，Service Worker 会主动拦截请求并决定从缓存或网络返回资源。检查是否有注册 SW 以及其更新策略（cache-first、network-first 等）。 关键点：很多“看到旧版”的投诉，最后发现是 Service Worker 缓存策略在作怪。
四、对站长的可操作建议（立刻能做）
- 静态资源使用带 hash 的文件名（比如 app.abc123.js），并设置长缓存；HTML 设置为 no-cache 或短 TTL，确保页面能检测到新版本并加载新的资源名。
- 部署脚本里加入 CDN cache purge 或版本切换触发（例如修改 index.html 的版本号）。
- 在服务端正确实现条件响应（304），确保 ETag/Last-Modified 有意义且一致。
- 检查是否存在 Service Worker：如有，确保其 update 流程与发布流程一致（SW 在 activate 后能正确清理旧缓存）。 示例（Nginx 设置静态文件缓存）： location ~* .(?:css|js|jpg|jpeg|png|gif|svg)$ { expires 365d; add_header Cache-Control "public, max-age=31536000, immutable"; }
五、普通用户如何短期解决？
- 强制刷新（Ctrl+F5 / Shift+刷新）或清除浏览器缓存；
- 在地址后加上随机查询参数（如 ?v=1.2）临时绕过缓存；
- 等待一段时间（如果是 CDN 缓存，通常在 TTL 到期后会自动更新）。
结语 从网友翻出的旧版对比来看，关键点往往不是“界面变了”而是“缓存策略与部署细节不同”。排查顺序建议先看响应头，再看是否有 CDN/Service Worker 干预，最后检查部署流程。若有新证据或进一步的抓包数据，我会继续补充分析与具体修复建议。欢迎在评论区贴出你抓到的响应头或请求记录，大家一起对比定位。
