有人发现了一个细节 | 91官网，关于缓存设置的说法——我反复确认了两遍…？不排除还有后续

最近在检查 91 官网的加载行为时，偶然发现了一个容易被忽视但影响很大的缓存细节。为了确认不是偶然现象，我对同一页面和静态资源反复跑了两遍抓包与头信息检测，得到的结论让我不得不写下来分享给大家——尤其是负责网站性能与运维的同学。下面把我发现的情况、诊断步骤、优化建议和后续可能的方向，一并整理清楚，方便你快速排查与修正。

我看到的细节是什么

• 页面与静态资源的 Cache-Control 设置存在不一致：HTML 页面被设置为短缓存或 no-cache，而部分静态资源（如 js、css、图片）缓存策略不统一，有的没有版本化且设置了较长的过期时间。
• CDN 或代理层对某些响应返回了额外的缓存头（例如 s-maxage、X-Cache），导致与源服务器的预期行为不一致。
• 部分资源使用了 ETag，但 ETag 在不同节点间不一致，影响了缓存命中率。

我为什么反复确认了两遍

• 第一次是通过浏览器开发者工具（Network）观察加载请求与响应头，怀疑是缓存策略问题。
• 第二次用 curl -I 与线上工具（WebPageTest、GTmetrix）交叉验证，确认响应头与 CDN 行为一致，没有环境差异导致的误判。 两次独立的检测结果一致，排除了临时网络或浏览器缓存干扰，所以判断问题确实存在。

如何快速诊断你的网站缓存问题（步骤清晰可复现）

1. 浏览器检测（最快）

• 打开 Chrome DevTools → Network，勾选 Disable cache（在开发者工具开着的情况下禁用缓存进行比对），观察首次加载与刷新后的差别。
• 查看每个资源的 Response Headers：Cache-Control、Expires、ETag、Last-Modified、Age、Vary。

1. 命令行验证（稳定可靠）

• curl -I https://yourdomain/path/file.js
• 注意观察 Cache-Control、Expires、ETag、Age、Via 等字段。可以用 curl -H "Cache-Control: max-age=0" 再试一次，模拟强制刷新。

1. CDN/代理层检查

• 登录 CDN 控制台看是否有 Page Rules、缓存级别或自定义缓存头覆盖源站。
• 使用 CDN 的命令或界面清除缓存，并观察是否能立即反应。

1. 第三方工具（对比多地域）

• 用 WebPageTest、GTmetrix、Pingdom 等工具，从不同节点抓取页面，确认是否存在地域性缓存差异。

常见问题与示例值（直接可借鉴）

• HTML 页面：Cache-Control: no-cache, no-store, must-revalidate 或 Cache-Control: max-age=0, private
  说明：页面多为动态或频繁更新内容，短缓存避免用户看到旧内容。
• 静态资源（js/css/image）：Cache-Control: public, max-age=31536000, immutable（前提是文件名带有版本号或哈希）
  说明：长期缓存结合文件名指纹化，是最佳实践。
• API 接口：视数据特性而定，可用 Cache-Control: private, max-age=60 或 s-maxage 用于共享缓存策略。
• CDN 层共享缓存：如果希望 CDN 缓存可控，使用 s-maxage 和 Cache-Control: public 配合源端控制。

缓存失效与更新策略（几种常用做法）

• 文件名加版本号/哈希（最可靠）
  示例：app.8d7f3a.js — 每次构建生成新的文件名，旧文件可以长时间缓存。
• 查询字符串（cache busting）
  示例：app.js?v=20260130 — 部分 CDN/代理默认忽略查询字符串缓存策略，需确认支持性。
• 主动清理 CDN 缓存（Purge）
• 适用于紧急回滚，但不推荐作为常态更新策略，因为会增加边缘层负担。
• 设置短缓存+Revalidation
• 使用 ETag/Last-Modified 配合合理的 Cache-Control，让客户端发送条件请求以减少带宽。

一些容易忽略但会导致缓存命中率低的问题

• Vary 头被设置为过多字段（如 Vary: Accept-Encoding, User-Agent），导致缓存分裂。尽量仅在必要时使用。
• ETag 在不同后端生成方法不一致（例如包含主机名或时间戳），会导致边缘节点与源站无法匹配。
• 代理或防火墙修改了响应头（例如去掉 Cache-Control 或插入 private），确认中间链路配置。
• 又或者文件没有内容变化，但打包工具没有做指纹化，导致必须频繁拉取最新资源。

针对 91 官网的建议（可直接落地）

1. 检查并统一静态资源缓存策略：对 js/css/image 强制开启长期缓存并用文件名哈希管理版本。
2. HTML 页面保持短缓存或 no-cache，同时配合 CDN 的分层缓存策略（s-maxage 可用于共享缓存优化）。
3. 检查 CDN 的缓存规则与源站返回头是否发生覆盖，避免双重或冲突配置。
4. 验证 ETag 的生成方式，确保在多实例部署时一致或直接优先使用 Last-Modified。
5. 制定发布流程：构建产物自动上报版本号并触发必要的 CDN 缓存清理或使版本切换完成。

结论与后续 这次的发现主要集中在缓存头不一致与 CDN 行为差异上。我已反复确认两遍基本排除了偶发因素，但不排除在更多页面或更复杂的流量场景下会有其他体现。下一步可以做的是：

• 做一次全站的缓存头扫描（自动化脚本），把所有静态资源与页面的响应头做成清单对比。
• 在发布流程中加入缓存策略检查，确保每次上线都能得到一致的缓存行为。
  如果你需要，我可以帮你列出一份可直接执行的检测脚本与清单，或者根据你的站点配置信息给出更精准的优化方案。愿意的话把域名或部分响应头贴出来，我帮你做更细的分析。

本文标签： # 有人 # 发现 # 一个