我把关键点核对了一遍 ｜ 91网：关于缓存设置的说法——细节多到我怀疑人生…？不排除还有后续

我把关键点核对了一遍 | 91网：关于缓存设置的说法——细节多到我怀疑人生…？不排除还有后续

最近围绕“91网的缓存设置该怎么弄”的讨论真是热闹，信息多到让人头大。我把常见说法逐条核对了，亲自做了检查并整理出一份可操作的清单 — 既适合想快速修复性能问题的站长，也适合追求极致细节的技术人员。下面是经过验证后的结论与建议，照着走能省不少时间和来回折腾。

一、先把结论放在最前面（省你折腾时间）

• 静态资源（CSS/JS/图片）：可以大胆设置长缓存并使用文件指纹（hash）做版本管理。
• HTML 主文档：不要长期缓存，采用短缓存或协商缓存（ETag/Last-Modified）配合合理的变更发布流程。
• 登录、支付等敏感页面：务必禁止缓存或仅缓存到私有浏览器（private）。
• CDN 与源站的缓存策略要一致，清理策略（purge）和缓存命中率监控必须到位。
• 测试用 curl、浏览器 DevTools、CDN 返回头来确认真实生效情况，别只看管理面板的假象。

二、常见说法与我核对后的真相

• “把所有资源都设为一年缓存最稳妥”
  真相：静态文件可以，但必须保证文件名里有版本哈希，否则更新时用户会加载旧文件。
• “HTML 也可以长缓存，节省带宽”
  真相：只在严格的发布流程和版本化 HTML 的场景下才可，否则会造成内容延迟更新和用户看到旧页面。
• “CDN 自动就能解决所有缓存问题”
  真相：CDN 能极大提升速度，但缓存规则（基于路径、Query、Header 等）必须和源站配置一致，否则会出现命中低、缓存失效或缓存错误内容的问题。
• “Cookie 会影响缓存”
  真相：会的。带有 Set-Cookie 或 Cookie 的响应/请求通常不会被公共缓存（CDN、共享缓存）缓存，除非做特殊配置。

三、实际可用的响应头推荐（示例）

• 静态资源（版本化文件，如 app.12345.js）： Cache-Control: public, max-age=31536000, immutable
• 图片（频繁更新少的）： Cache-Control: public, max-age=2592000
• HTML 页面（可短缓存或协商缓存）： Cache-Control: private, no-cache, must-revalidate 或者：Cache-Control: max-age=60, stale-while-revalidate=30, stale-if-error=86400
• 登录/支付等敏感页面： Cache-Control: no-store, no-cache, must-revalidate

四、简单 nginx 配置片段（示例） （仅供参考，按你环境调整） location ~* .(css|js|woff2|woff|ttf|svg|png|jpg|jpeg|gif)$ { expires 365d; addheader Cache-Control "public, max-age=31536000, immutable"; } location / { proxypass http://backend; proxysetheader Host $host; # 对 HTML 使用短缓存或协商缓存 add_header Cache-Control "private, no-cache, must-revalidate"; }

五、如何验证缓存真的生效（实用命令）

• 查看响应头：curl -I https://example.com/app.12345.js
• 检查 CDN 标识：注意 x-cache / cf-cache-status / via 等头（不同 CDN 名称不同），例如 cf-cache-status: HIT 表示命中缓存
• 浏览器工具：Network 面板看资源是否从 Disk/Memory cache 或 200/304 返回
• 性能测试：Lighthouse / WebPageTest 比对缓存前后加载时间与请求数

六、那些容易被忽视但常出问题的细节

• Query string（?v=1）与缓存：许多缓存策略默认不缓存带查询字符串的请求，或把每个 query 作为不同对象，导致命中率下降。更可靠的是使用文件名哈希。
• Vary: Accept-Encoding / User-Agent：Vary 头会增加缓存分片，注意不要无谓地添加会降低命中率。
• Set-Cookie：源站对页面设置 Set-Cookie 会让公共缓存回避缓存该响应。
• 代理、负载均衡层的干预：有些中间件可能会在不通知的情况下修改头部，线上一定要抓包或用 curl 来排查。
• 缓存清理（Purge）：自动化脚本或部署流程里一定要包含清除 CDN/缓存层的步骤，避免发布后用户仍看到旧文件。

七、部署与发布建议（流程化）

• 版本化静态资源（文件指纹），并在构建后自动替换页面引用。
• 对于频繁变更的内容，采用短缓存并利用 stale-while-revalidate 来平衡体验与新鲜度。
• 部署脚本里加入 CDN purge（按文件或按路径），并在发布后自动验证缓存状态。
• 把监控（缓存命中率、响应时间）纳入日常监测，设置告警。

八、快速自查清单（按步骤走） 1) 用 curl -I 检查关键资源的 Cache-Control、Etag、Last-Modified、CDN 头。 2) 在浏览器 DevTools 下实际刷新页面，观察是否从缓存加载。 3) 进行一次文件无版本更新，确认用户能否立刻看到更新（或者通过 purge 生效）。 4) 检查包含 Cookie 的响应是否被意外缓存或未缓存。 5) 审查 Vary、Set-Cookie、QueryString 的使用是否合理。 6) 确认 CDN 与源站的缓存规则一致，并测试跨区域命中情况。

九、风险与折衷（别被“性能”绑架）

• 长缓存带来高命中但会降低内容更新速度；短缓存提高新鲜度但会增加请求数与带宽。
• 在对 SEO、动态内容和用户体验之间需要拿捏，通常：
• 静态资源：偏向长期缓存
• 动态/可交互页面：偏向短缓存或协商缓存
• 敏感操作：严格不缓存