有人发现了一个细节；91官网——91网页版，关于缓存设置的说法 | 连老用户都容易中招。我先把要点列出来
在日常使用网站时，缓存常被当成“速度加速器”，但细节设置不当就会变成“信息滞后器”。最近有人发现91官网（91网页版）在缓存策略上存在一些容易混淆的点，连长期用户都被旧页面、旧登录状态或错误资源困扰过。本文把要点、排查方法和站点/开发者的对策都整理好了，方便直接发布与参考。
1) 常见症状（为什么老用户也会中招）
- 页面明明更新了，但你看到的还是旧内容。
- 登录或权限变更后仍显示为未登录或信息不同步。
- 图片、样式或脚本加载异常，版本不一致。
- 表单提交后结果不更新，反而加载缓存响应。
2) 用户能做的快速排查与解决（几步就能试）
- 强制刷新：Windows 上 Ctrl+F5；Mac 上 Cmd+Shift+R。
- 无痕/隐身窗口打开网站，看问题是否还存在。
- 清除浏览器缓存：
- Chrome：菜单 > 更多工具 > 清除浏览数据；或 F12 打开 DevTools → Application → Clear storage。
- Firefox：菜单 > 设置 > 隐私与安全 > 清除历史记录。
- Safari（Mac）：开发者菜单 > 清空缓存（若没开开发者菜单，Safari 设置 → 高级 → 勾选“在菜单栏显示开发”）。
- 移动端：Chrome for Android 菜单 > 历史记录 > 清除浏览数据；iOS Safari 在设置里清除网站数据。
- 临时禁用 Service Worker（高级用户）：Chrome DevTools → Application → Service Workers → Unregister 或勾选 “Update on reload” 后刷新。
这些方法能解决绝大多数由缓存残留造成的问题。
3) 站点/开发者应做的核心设置（防止用户频繁被坑）
- 静态资源（图片、脚本、样式）采用文件指纹（hash）或版本号，并设置长缓存：
- Cache-Control: public, max-age=31536000, immutable
- 动态页面与敏感数据设置短缓存或不缓存：
- Cache-Control: no-cache, no-store, must-revalidate
- Pragma: no-cache（兼容旧浏览器）
- 使用 ETag 与 Last-Modified 做条件请求，减少不必要的流量但保证更新可见。
- CDN 策略：对静态资源用长 TTL + 变更时走版本化或触发 CDN 清理（Cloudflare、Fastly 等提供按文件或全部清理功能）。
- Service Worker 策略：在更新逻辑中实现“旧版卸载→新版激活”并提供显式的更新提示，避免旧缓存无限驻留。
- Headers 示例参考：
- 静态文件：Cache-Control: public, max-age=31536000, immutable
- 动态页面：Cache-Control: no-cache, no-store, must-revalidate
- 条件请求：ETag: "abcdef123456"
- 对 API 接口明确区分缓存策略：认证/用户数据不缓存，公共只读数据可使用短 TTL 或响应头控制。
4) 常见误区（避免走弯路）
- “把所有东西都不缓存就万无一失” —— 会显著影响性能与带宽。正确做法是区分动态与静态资源。
- “URL 后加 ?v=1 就够了” —— 仅当你严格管理版本号并强制更新时有效；更可靠的是文件名指纹或构建时自动加哈希。
- “CDN 已经有缓存，浏览器就没必要管” —— 浏览器和 CDN 各自缓存逻辑不同，头控制需一致配合。
5) 给91网页版的建议清单（快速对照）
- 静态资源：文件指纹 + 长 TTL + CDN
- 登录/个人页面：no-store/no-cache
- API：根据数据敏感度设置合理 TTL
- Service Worker：实现可控更新机制并在页面显式提示“有新版本，点击刷新”
- 提供用户帮助页：列出“如何清缓存/强制刷新”的操作步骤，减少用户投诉
结语 缓存是性能和正确性之间的平衡器，设置得好用户体验飞跃，设置不当连老用户也会中招。无论你是普通访问者，还是91网页版的维护者，按上面的排查步骤与配置要点去做，绝大多数缓存引起的问题都能被快速定位并解决。如果需要，我可以把“用户帮助页”的文字版本整理成一页可直接放在网站上的操作指南，或者把推荐的 HTTP 头配置写成可复制的服务器配置片段。要哪种我继续给你准备。