我把关键点核对了一遍 - 91网页版：关于缓存设置的说法｜我反复确认了两遍。据说后面还有更大的反转
引子 最近围绕 91 网页版的缓存设置出现了不少说法：有人主张全面长缓存以提升速度，也有人认为应当彻底禁用缓存以保证数据实时性。为了弄清真相，我把关键点核对了一遍，并且重复验证了两遍。下面把核对过程、结论和实用建议整理出来，供你直接照着执行或作为参考判断。
缓存基础快速回顾
- 浏览器缓存（Browser Cache）：基于 Cache-Control、Expires、ETag、Last-Modified 等响应头，决定资源是否从本地加载。
- CDN 缓存：把静态资源分发到边缘节点，减少源站负载和延迟，但需要注意缓存失效策略与清理机制。
- 反向代理/缓存（如 Nginx、Varnish）：常用于 HTML 页面级别的缓存控制。
- Service Worker：可在客户端更细粒度控制缓存，实现离线或高级策略。
- 版本化（Fingerprinting）：通过文件名包含哈希来实现长期缓存和安全回收。
市面上常见说法与我的核验结论 常见说法一：把所有资源都设为长缓存（如一年），页面会瞬间变快。
- 核验结论：对静态且带版本号的资源（JS、CSS、图片）适用，效果明显。对 HTML 或会频繁改动的资源则不可取，会导致用户看到旧内容。
常见说法二：禁用缓存可避免用户看到旧数据，是最安全的选择。
- 核验结论：在某些场景（敏感实时数据、强一致性需求）有道理，但全站禁用会大幅增加服务器负载并拉长加载时间。更好的做法是分层策略。
常见说法三：只靠 CDN 自动就万无一失。
- 核验结论：CDN 是必要的，但需正确设置源站响应头、缓存键（是否包含 Cookie、Query）和缓存清理策略。否则会出现“缓存不生效”或“清理不彻底”的问题。
我如何核验（两遍验证的流程）
- 观察与采样：在开发者工具与线上抓包中观察响应头（Cache-Control、ETag、Age、X-Cache 等）。
- 命令行验证：使用 curl -I、curl -H "Cache-Control: no-cache" 等命令，检测缓存命中与回源行为。
- CDN 控制台与日志：检查边缘节点返回头与清理历史，确认缓存 TTL 与 Purge 实际生效情况。
- 多场景测试：手机与桌面、登录态与游客、带 Query 与不带 Query，单页应用（SPA）与多页面（MPA）分别测试。
- 回归验证：在修改缓存策略后再次执行上述步骤，确认实际效果与预期一致。
推荐的实战缓存策略（可直接复制粘贴到配置里）
- 静态资源（通过版本号/文件指纹）
- Cache-Control: public, max-age=31536000, immutable
- 说明：长期缓存，依赖文件名变更来失效。
- HTML 主文档
- Cache-Control: no-cache, must-revalidate
- 或：Cache-Control: public, max-age=0, s-maxage=60
- 说明：允许 CDN 缓存短时间（比如 60 秒），浏览器每次可用 ETag/Last-Modified 做校验，及时回源获取更新。
- API 响应（含用户专属数据）
- Cache-Control: private, no-store 或 private, max-age=0, must-revalidate
- 说明：避免 CDN 或共享缓存泄漏用户数据。
- 静态资源子域名或无 Cookie 的域
- 把静态资源放到静态子域（如 static.example.com），响应头去掉 Set-Cookie，提升 CDN 与浏览器缓存效率。
- Service Worker
- 用于离线体验或高级缓存，注意版本控制和更新策略（skipWaiting + clients.claim 的副作用需评估）。
- 缓存清理（Purge）策略
- 自动化：在 CI/CD 发布流水线中加入 CDN Purge 或更新资源指纹。
- 手动备选：在紧急修复时提供即时清理手段，并监控清理结果。
测试与监控清单（落地可操作）
- 快速检测
- curl -I https://yourdomain/resource
- 在 DevTools Network 查看 Size、Status（200 vs 304）、Timing、Response Headers
- CDN 指示器
- 检查 X-Cache、X-Cache-Hits、Age 等头部字段
- 性能工具
- Lighthouse / WebPageTest：测量实际加载时间与缓存影响
- 日志与监控
- 关注缓存命中率、回源流量、源站响应时间。设置告警阈值（回源流量突增或命中率骤降）。
常见坑与规避建议
- HTML 长缓存导致用户看到旧页面：把 HTML 设置为短缓存或启用 ETag。
- CDN 缓存键包含 Cookie，导致缓存效果失效：为静态资源配置无 Cookie 策略，或使用专属子域。
- 版本未严格执行：不要只靠 Query String 更新版本（部分 CDN 可能忽略），推荐文件名指纹。
- 清理不及时：把 Purge 流程纳入发布流水线，避免手动操作遗漏。
- Service Worker 管理不当导致“永远旧版本”：在发布策略里加入合适的激活与更新逻辑，并告知用户必要时刷新页面。
结论与下一步 两轮核验的结论很明确：一个粗暴的“全部长缓存”或“全部禁用缓存”都不是正确答案。按资源类型分层策略、结合 CDN 与自动化发布的缓存清理、并做好监控，才是可持续的做法。针对 91 网页版，目前推荐的落地方案是：
- 静态资源长期缓存并文件名指纹；
- HTML 短缓存或使用 ETag + CDN 短 TTL；
- 敏感或用户特有数据禁止共享缓存；
- 在 CI/CD 中加入自动化 Purge 和发布后验证步骤。