别只看表面，91官网的隐藏选项不神秘，关键是缓存管理怎么理解（建议反复看）
别只看表面，91官网的隐藏选项不神秘，关键是缓存管理怎么理解（建议反复看）
表面上看，网站的“隐藏选项”像是某种玄学，但大多数情况下，那些看起来神秘的行为都与缓存（cache）有关：页面没及时更新、点击某个开关不起作用、调试时总是看到旧资源……如果把缓存的机制理解清楚，很多“隐藏选项”就变得不再神秘。下面把常见场景、诊断方法和可落地的解决策略罗列清楚，方便直接拿去操作。
一、先搞清楚“缓存”有哪些类型
- 浏览器缓存：HTML、CSS、JS、图片等被保存在本地，用以加速后续访问。
- CDN缓存：分布式节点缓存静态资源，减少源站压力。
- 代理/网关缓存（例如反向代理、负载均衡器）。
- 服务端缓存（例如 Redis、Memcached，用来缓存接口或渲染结果）。
- Service Worker 缓存：单页应用或离线功能常用，会独立于浏览器缓存。
- 本地存储（localStorage/sessionStorage）、IndexedDB：不是传统缓存，但会保存状态或配置，影响页面表现。
二、“隐藏选项”通常在哪里出现
- 开发者模式参数：URL 中的 ?debug=true、?v=timestamp 等。
- 后台或用户面板里对缓存策略的开关（如清理缓存、开启 CDN 缓存）。
- Service Worker 脚本里的缓存策略控制。
- 浏览器本地存储或 Cookie：网站用它记录用户偏好或版本标记。
- 网络层（CDN、代理）静默生效、不在前端 UI 明显展示。
三、排查缓存问题的实用工具与方法
- 浏览器开发者工具（F12）
- Network 面板：勾选 “Disable cache” 并刷新，观察资源是否来自 (from disk cache)/(from memory cache) 或 304/200。
- Application 面板：查看 Service Workers、Local Storage、Cookies、Cache Storage，直接清理或注销 Service Worker。
- curl 检查响应头：curl -I https://example.com/path
- 关注 Cache-Control、Expires、ETag、Last-Modified、Age、Vary 等。
- 查看 CDN/代理控制台：许多 CDN 提供缓存命中率和缓存条目的查看与清除接口。
- 用隐身窗口或不同网络环境测试，排除本地浏览器缓存与 DNS 缓存的影响。
四、常见响应头与含义（便于判断）
- Cache-Control: max-age=31536000, immutable → 长期缓存，适合带版本号的静态资源（如带 hash 的文件名）。
- Cache-Control: no-cache 或 must-revalidate → 客户端每次需向服务器验证资源是否更新（仍可使用 304）。
- Expires:
→ 旧式缓存控制，优先级低于 Cache-Control。 - ETag / Last-Modified → 条件请求校验，服务端返回 304 表示未修改。
- Vary: Accept-Encoding 或 Cookie → 告诉缓存如何区分不同请求，影响缓存命中。
五、遇到页面更新不生效，先试这几步（用户向）
- 强制刷新：Windows 通常是 Ctrl+F5 或 Ctrl+Shift+R；macOS 通常是 Cmd+Shift+R。
- DevTools Network 中勾选 Disable cache 后刷新。
- 清除站点数据：Application → Clear storage → Clear site data。
- 注销或移除 Service Worker（Application → Service Workers → Unregister）。
- 用隐身模式或换浏览器验证是否依旧存在。
六、开发/运维的缓存策略建议（可直接应用）
- 静态资源（CSS/JS/图片）
- 使用内容哈希（filename.hash.ext）配合长缓存（Cache-Control: max-age=31536000, immutable）。这样文件名变更时会自动失效。
- HTML 与 API 接口
- 对于频繁更新的 HTML 页面或动态内容，设置短缓存或 no-cache 并配合 ETag/Last-Modified 做条件请求，保证用户能及时拿到更新。
- 服务端缓存与 CDN
- 为不同类型资源设计不同 TTL：静态资源长缓存、动态接口短缓存或不缓存。
- 利用 CDN 的缓存分层与回源策略，并配置合适的缓存键（是否包含 Cookie、Query 参数）。
- 部署与版本管理
- 每次发布时更新静态资源的版本标识（文件名或公共 query 参数），并在发布流程中自动触发 CDN 清理/回源刷新。
- Service Worker
- 谨慎使用缓存优先策略：常用的做法是 network-first 或 stale-while-revalidate，确保重要数据优先从网络获取，避免长期离线缓存导致内容无法更新。
- 安全/隐私
- 对包含用户敏感信息的响应要禁止缓存（Cache-Control: no-store），避免在共享设备上泄露。
七、实操示例（若干可复制命令与配置）
- 用 curl 看响应头：
- curl -I https://91example.com/static/app.js
- 读出 Cache-Control、ETag、Age 等字段，判断是否被 CDN 缓存或是新版本。
- Nginx 示范（静态资源长缓存）：
- location ~* .(js|css|png|jpg|jpeg|gif|svg)$ { expires 365d; add_header Cache-Control "public, max-age=31536000, immutable"; }
- 怎样做缓存“瞬间失效”：
- a) 使用文件名哈希（最推荐）；
- b) 如果不能改文件名，部署时在引用处加版本号 ?v=20260220；同时调用 CDN 的 purge API 清除旧缓存。
- 清 Service Worker 的快捷方法（浏览器控制台）：
- Application → Service Workers → Unregister，或者在控制台运行 navigator.serviceWorker.getRegistrations().then(rs => rs.forEach(r => r.unregister()));
八、发布/调试清单（发布时逐条核对）
- 静态资源是否带有版本哈希？
- HTML 与关键 API 的 Cache-Control 是否合理？
- CDN 是否配置正确（缓存规则、缓存键、回源行为）？
- 是否在发布脚本里调用了 CDN 清理或让版本号生效？
- Service Worker 是否随着新版同步更新了缓存策略？
- 本地测试是否通过（禁用缓存、隐身窗口、不同设备）？
结语 很多看起来“隐藏”的选项，其实是缓存在作祟。把缓存的层级、控制点和常见响应头熟悉后，问题就能被逐步拆解：用户端用强制刷新和关闭缓存来排查，开发端用哈希命名、合理的 Cache-Control 与 CDN 策略来避免“旧资源”困扰。多做几次发布与调试流程，涉及的“隐藏选项”会越来越透明。建议把上面的排查步骤和发布清单保存下来，遇到类似问题时按步骤走一遍，能省下大量摸索时间。
