别只看表面，91在线的隐藏选项不神秘，关键是缓存管理怎么理解（一条讲透）
很多人在使用 91在线 等现代 Web 应用时，会发现一些“隐藏选项”或者行为看起来很神秘：页面改了但你看不到更新、功能开关悄悄生效、调了参数没变化……很多时候问题的根源并不是功能被藏起来，而是缓存在起作用。下面一条把缓存管理的原理、排查方法和实用对策讲清楚，让你真正把“隐藏选项”变成可控选项。
一、什么是“隐藏选项”？为什么看起来神秘
- 真正的隐藏选项：后台未公开的参数、调试开关、URL 上的未记录参数。
- 表面“隐藏”的行为：缓存、Service Worker、CDN、浏览器存储（localStorage、IndexedDB）等会让页面表现和真实服务器状态不同步，从而产生“看不到变化”的错觉。 结论：遇到“明明改了却没生效”，先把缓存相关环节排查一遍，往往能找到原因。
二、缓存的几个关键环节（从用户到服务端）
- 浏览器 HTTP 缓存（Cache-Control、ETag、Last-Modified）：控制静态资源（JS/CSS/图片）何时被重用。
- Service Worker & Cache Storage：离线能力和更激进的缓存策略，会直接拦截网络请求并返回缓存响应。
- CDN 缓存：分布式边缘缓存，会在边缘节点返回旧资源直到被清理或失效。
- 应用存储（localStorage、IndexedDB、sessionStorage）：持久化数据会影响页面逻辑。
- 代理/网关缓存：中间件可能缓存 API 响应。
三、常见症状与快速排查方法（用户/开发者均适用） 症状：页面显示旧样式或旧逻辑
- 排查：按 Ctrl+F5 或 Cmd+Shift+R 强制刷新。若有效，说明是浏览器/CDN 缓存问题。 症状：仅在某台设备/某浏览器出现
- 排查：使用浏览器无痕窗口或不同浏览器/设备访问。如果无痕有效，检查 localStorage、Service Worker。 症状：明明后端已改，但前端接口返回旧数据
- 排查：检查响应头的 Cache-Control、ETag；若走 CDN，尝试直接命中源站或查看 CDN 缓存状态。 症状：服务工作线程（SW）控制页面，刷新也无效
- 排查：Chrome DevTools → Application → Service Workers，尝试 unregister 或勾选 “Update on reload” 并清除 Cache Storage。
四、开发者的缓存管理策略（实用、易操作） 目标是保证用户既能享受缓存带来的性能，又能在发布新版本时及时获得更新。
1) 静态资源采用文件名指纹 + 长缓存
- 原则：资源名带版本哈希（eg. app.abc123.js），配合 Cache-Control: max-age=31536000, immutable。
- 效果：部署新版本时文件名变更，浏览器直接请求新文件，旧文件可长期缓存。
2) 动态内容 / API 设置合理缓存策略
- 对于实时或频繁变更的接口，使用 Cache-Control: no-cache 或 no-store；如果允许短期缓存，使用 max-age 并结合 ETag/Last-Modified。
- Vary 头：当响应依赖于请求头（如 Accept-Language、Authorization）时设置 Vary。
3) Service Worker 更新流程要规范
- 常见做法：
- install 事件中缓存必要资源到带版本的 cache 名称（cache-v1）。
- activate 事件中删除旧的 cache（cache-v0）。
- 发布新版本时更新 service-worker.js（文件内容变化触发浏览器下载新 SW）。
- 使用 skipWaiting() 与 clients.claim() 可加速新版本生效，但建议配合“有新版本，提示用户刷新”的 UX，避免强制中断用户操作。
- 缓存策略示例（代码思路）：
- 对静态资源采用 cache-first（快速命中 + 后台更新检查）。
- 对 API 使用 network-first（优先网络，失败则回退缓存），并在成功时更新缓存。
4) CDN 与部署策略
- 文件名指纹 + 低 TTL 的 HTML（一旦 HTML 引用新哈希文件即可生效）。
- 发布时触发 CDN 清理或使用版本化路径避免手动清理。
- 页面级 HTML 不要设置长缓存：Cache-Control: no-cache 或短 ttl，让浏览器频繁获取最新引用。
五、实用举措（分别针对普通用户和站点管理者） 对普通用户：
- 试试强制刷新（Ctrl/Cmd+F5）、无痕窗口或清除浏览器缓存。
- Chrome DevTools → Application：查看并清除 Service Workers、Cache Storage、localStorage。
- 如果是移动端应用，尝试重启 App 或清除应用缓存。
对站点/产品负责人：
- 采用静态资源指纹化（content-hash）并设置长缓存。
- 确保 HTML 与入口文件短缓存或 no-cache，让客户端能及时拿到新资源引用。
- 在发布流程中自动清理 CDN（或使用版本化路径）。
- 优化 Service Worker 更新策略并在 UI 中提供“检测到新版本，点击刷新”的提示。
- 对关键 API 依据数据特性设置缓存策略（例如排行榜/配置类可短期缓存，用户敏感数据 no-store）。
六、一些常见误区
- 误区：把所有东西都交给 Service Worker 管理能解决一切。
- 现实：SW 很强，但策略不当会导致“修复很久才生效”的问题。SW 应与服务器缓存和部署流程配合。
- 误区：设置长缓存就一定更快/更好。
- 现实：静态资源适合长缓存，动态内容或 HTML 则不宜长时间缓存，否则会影响更新频率。
- 误区：只在客户端处理缓存问题就够了。
- 现实：服务端响应头、CDN配置和部署流程同样关键。
七、实战小贴士（命令和 Header 示例）
- 强制不缓存的 HTTP 头（适合 API）：Cache-Control: no-store, no-cache, max-age=0, must-revalidate
- 静态文件长期缓存示例：Cache-Control: public, max-age=31536000, immutable
- ETag/Last-Modified：配合 If-None-Match/If-Modified-Since 使用，减少带体积更新的传输。
- 发布脚本建议：构建产物带哈希 → 上传 CDN → 更新 HTML 引用 → 短 TTL HTML 保证新引用被及时拉取。
结语：隐藏不等于神秘，缓存管理就是关键 当你面对“明明改了却没更新”的情形，先把缓存链路从浏览器、Service Worker、CDN 到服务器逐一排查。对开发者来说，采用文件指纹、合理的 Cache-Control、规范的 Service Worker 更新和自动化 CDN 清理，是让版本可控同时保证性能的稳妥方案。对用户来说，掌握几条简单操作（强制刷新、无痕、清除 SW/缓存）就能把“隐藏选项”还原为可见的设置。
如果需要，我可以根据你在 91在线 上遇到的具体问题（页面 URL、出现的旧资源路径或响应头截图）帮你逐步定位并给出可执行的发布/修复建议。
