这个坑最近特别多人踩：91官网｜关于缓存设置的说法——细节多到我怀疑人生…？如果属实，那就太刺激了
最近社群里关于“91官网的缓存设置有问题”的讨论炸开了锅——有人说页面长时间不更新、有人说用户看到别人的内容、还有人怀疑是为了节省带宽故意把缓存配得奇怪。作为一个折腾过各种站点缓存配置的老手，我把这些说法拆开来讲清楚，告诉你哪些可能是真的、哪些只是听起来刺激但成立性低，以及你能怎么查证和修复。
先说两句常识：缓存并非单一东西 缓存分层很多——浏览器缓存（Cache-Control / Expires）、CDN/边缘缓存（例如 Cloudflare、Fastly）、反向代理（Varnish、Nginx）和应用层缓存（Redis、内存缓存）。同一资源同时被多个层缓存，配置任一层不当都会造成问题，但表现各不相同。
常见说法与真相概率
- “页面更新后用户仍看到旧内容”：高度可能。原因通常是 HTML 被 CDN 或代理缓存且 TTL 过长，或者没有在部署时触发缓存失效（cache-busting）。
- “用户看到别人的私有内容”：中等可能。常见根因是把带有认证或会话相关头（Set-Cookie、Authorization）/用户特定查询字符串的响应当作可共享缓存（public）处理，或者 Vary 头没设好。
- “缓存被用来作弊/统计造假”：可行性低但存在可能性，更多时候是日志与统计延迟或埋点问题，而非纯缓存配置导致。
- “故意把缓存搞奇怪以节省带宽”：有可能。站长有时会为静态资源设置极长TTL来节省流量，但若误把动态页也设置长 TTL，就会带来严重问题。
如何快速查证（实操）
- 用 curl 看响应头：curl -I https://91website.example/page
关注：Cache-Control、Expires、Age、ETag、Last-Modified、Vary、Set-Cookie。Age 表示边缘已有多久，Cache-Control 指示可缓存策略。 - 用无痕/不同设备访问比对内容：确定是不是个别浏览器缓存问题或全球边缘节点差异。
- 在 CDN 管理面板看缓存命中率（cache hit ratio）和最近的缓存规则。
- 部署后立即改版本号或请求带时间戳的 URL，看更新是否即时反映（验证缓存失效流程）。
典型坑与细节（工程角度）
- 把动态 HTML 标注为 public max-age 很长 → 用户看到历史页面。
- 忽略 Vary 头（例如 Vary: Cookie / Accept-Encoding），导致不同用户内容混淆。
- 使用 Set-Cookie 在本不该带 cookie 的静态请求中 → CDN 可能不会缓存或缓存不一致。
- 静态资源没做指纹化（fingerprint/version）→ 更新难以迅速生效。
- CDN 覆盖源站 Cache-Control 设置，导致预期失效（或反之）。
- 未配置好缓存清除（Purge）或版本化部署流程，导致回滚/发布后仍被旧缓存服务。
如果属实，会有哪些后果
- 用户体验变差：重要内容延迟更新、功能性 bug 持续出现。
- 隐私与安全风险：误缓存用户专属页面可能泄露信息。
- SEO问题：搜索引擎抓取到过时内容或重复内容，影响收录。
- 业务/品牌声誉受损：用户抱怨、投诉增多，可能进而影响流量和收入。
实用建议（给站长的迅速清单）
- HTML 页面：设置短 TTL 或使用 no-cache/private，根据是否存在用户个性化决定。
- 静态资源（JS/CSS/图片）：长期缓存 + 文件名指纹（例如 app.v123.js）。
- 敏感/用户专属内容：使用 Cache-Control: private 或 no-store。
- 全站监测：部署后用 Lighthouse/WebPageTest、并在 CDN 看命中率。
- 缓存失效策略：把清缓存（Purge）纳入 CI/CD 流程，或使用版本化 URL。
- 验证流程：用 curl 检查头、用不同 IP/设备测试、查看 CDN 监控与日志。
- 若怀疑隐私泄露：立刻把相关资源设置为 private/no-store 并排查日志与缓存命中记录。
