这事越传越离谱；91大事件，关于缓存设置的说法，原来大家都误会了？！我先把要点列出来

先把要点列出来（可以直接照着查、改、测试）：

• 缓存不是万能药：正确思路是“长期缓存静态、短期或禁用缓存动态”，并配合版本号或指纹（fingerprint）。
• Cache-Control 的指令比 Expires 更可靠：推荐用 Cache-Control 为主、Expires 作为兼容项。
• no-cache ≠ no-store：no-cache 会强制浏览器向服务器验证资源是否变化；no-store 则完全不缓存。
• 对于带版本号的静态资源，用 long max-age + immutable；对 HTML 或用户专属页面，用短 TTL 或 no-store/no-cache。
• ETag 与 Last-Modified 是协商缓存的两个手段，ETag 更精确但在多机部署下需小心一致性。
• CDN 与浏览器缓存是两套机制：上线需处理 CDN 缓存失效（purge）或用版本化文件避免手动清除。
• Service Worker 的缓存独立于 HTTP 缓存，更新策略需要和服务器缓存策略配合考虑。
• Vary 头用得不好会导致缓存爆炸（导致缓存命中率降低或占用大量边缘缓存）。
• query string 做版本号兼容性好，但某些 CDN 可能默认对 query string 不当作缓存键（需确认设置）。
• 先测再改：用 curl、浏览器 DevTools、Lighthouse、CDN 日志来验证生效情况。

下面把这些要点逐条展开，给出实操建议、示例与排查步骤。

一、缓存的本质和常见误区

• 本质：缓存是为了减少重复下载、降低延迟、减轻后端压力。设计缓存策略的目标是“稳定且可控的内容更新”与“高命中率”之间的平衡。
• 误区1：把所有文件都设置很长时间就万事大吉。实际后果是更新困难、用户看到旧内容。
• 误区2：ETag 总比 Last-Modified 好。ETag 精确，但在多实例（或不同部署方式）下可能导致无意义的变化，反而降低命中。
• 误区3：只靠 CDN 自动刷新就够了。很多团队忽略 CDN 的缓存键、分发延迟或 API 限制，导致生效不及时。

二、关键 HTTP 头及其用法（实战建议）

• Cache-Control（首选）
• static（带版本的文件，如 app.abc123.js）： Cache-Control: public, max-age=31536000, immutable 说明：一年缓存、immutable 表示资源内容不会变化（配合文件名带 hash）。
• HTML（频繁变动或用户相关）： Cache-Control: no-cache, must-revalidate, max-age=0 说明：浏览器在使用前会向服务器验证内容是否变化（更安全且保留协商缓存优势）。
• 私有用户数据页面： Cache-Control: private, no-store 说明：不允许共享代理缓存，no-store 阻止任何持久存储。
• Expires
• 可以作为兼容项，但当有 Cache-Control 时通常被覆盖。建议仍设置合适的 Expires 作为后备。
• ETag / Last-Modified
• ETag 精确：服务器返回 ETag，之后客户端用 If-None-Match 请求，服务器返回 304。
• Last-Modified 配合 If-Modified-Since，粒度是时间戳，可能不够精确。
• 实操建议：单机或能生成稳定 ETag 的系统可以用 ETag；多机或有代理变更的场景优先用 Last-Modified +短 TTL 或使用文件指纹。
• Vary
• 用来表明响应与哪些请求头有关（如 Vary: Accept-Encoding, Cookie）。
• 风险：指定过多或误用（如把全套请求头写进 Vary）会使每种组合都产生独立缓存条目，导致缓存爆炸。

三、静态资源（CSS/JS/图片）的最佳实践

• 强制版本化文件名（content-hash）：app.abc123.js、style.4f2e.png。
• 版本化 + 长缓存（Cache-Control: public, max-age=31536000, immutable）。
• 切忌对 fingerprinted 资源使用 no-cache 或短 TTL。
• 如果无法改文件名，使用 query string 作为版本（?v=1.2.3），但要确认 CDN 对 query string 的缓存键策略。

四、HTML 与 API 的处理策略

• HTML 页面（模板化、频繁更新）
• 推荐短 TTL 或 no-cache + 协商缓存（ETag/Last-Modified + max-age=0）。
• 如果页面对登录用户不同，使用 Cache-Control: private。
• API 返回（有用户敏感信息）
• 对于返回结果不允许缓存，用 Cache-Control: no-store。
• 对于可缓存的公共 API，使用合适的 max-age 并配合 ETag 或版本化路径。

五、CDN、反向代理与缓存清理

• CDN 的缓存键（包括是否把 Query String 纳入）必须确认并根据需求配置。
• 部署新版本时常见做法：
• 优先使用文件指纹，避免主动清理。
• 对于非指纹化文件，触发 CDN purge（注意 API 限制和延迟）。
• 缓存层级：浏览器缓存 → CDN/边缘缓存 → 源站缓存。变更时需同步考虑每一层。

六、Service Worker 的特殊注意点

• Service Worker 的缓存独立，且控制范围通常覆盖整个站点或子路径。
• 更新 SW 时要设计好缓存名称（如 cache-v2）并在 activation 阶段清理老缓存。
• 更改静态资源后，需要确保 SW 逻辑能正确检测到新版本并更新缓存，而不是把旧资源一直发给用户。

七、常见问题与排查方法（实用命令和步骤）

• 快速查看响应头： curl -I https://example.com/path/file.js
• 验证资源是否返回 304：在 DevTools Network 面板里看 Status 为 304 或 200。
• 模拟无缓存请求： curl -H "Cache-Control: no-cache" -I https://example.com/
• 检查 CDN：从不同地区查看缓存命中（或使用 CDN 提供的缓存命中率统计）。
• 如果怀疑 ETag 导致问题：在不同后端实例上生成相同资源并检查 ETag 是否一致。
• 如果 Vary 导致缓存爆炸：检查响应头是否含有不必要的 Vary 条目（例如 Vary: * 是危险的）。

八、典型配置示例（可直接复制到服务器或 CDN 的 header 配置）

• 指纹化静态资源（推荐）： Cache-Control: public, max-age=31536000, immutable
• 非指纹化但不常变的资源： Cache-Control: public, max-age=86400
• HTML（模板）： Cache-Control: no-cache, must-revalidate, max-age=0 ETag: "abcdef12345"
• 用户专属或敏感数据： Cache-Control: private, no-store

九、落地部署的检查清单（上线前逐项跑一遍）

• 静态资源是否都做了指纹化？没有则确认是否有 CDN purge 流程。
• HTML 是否设置为短 TTL 或 no-cache？是否使用了合适的 ETag/Last-Modified？
• CDN 的缓存键和 query string 策略是否符合预期？
• Service Worker 是否有版本更新策略及旧缓存清理？
• 是否避免对敏感 header 缓存（如 Set-Cookie 不应被边缘缓存）？
• 用 curl + DevTools + Lighthouse 在不同网络环境下测试首次加载与重复加载行为。
• 确认错误页面（如 404/500）是否配置合理缓存，避免长期缓存错误页面。

十、结论（简短版） 缓存策略不是“随便设一个长时间就省事”，而是需要把资源类型、更新频率、CDN 行为和服务端生成方式结合起来设计。把静态资源做指纹并长期缓存，把 HTML 和用户相关内容短缓存或禁用缓存，再配合 ETag/Last-Modified 做协商，最后别忘了测试和 CDN 同步策略，99% 的“缓存出问题”都能被握在手里解决。

如果你愿意，我可以：

• 根据你的站点结构给出一套具体 header 配置（把常见 URL 列出来就行）；
• 帮你写一个部署前的检查脚本或清单，便于 CI/CD 集成；
• 或直接演示如何用 curl + DevTools 验证某条规则是否生效。

要不要把你站点的几类资源路径贴上来？我可以按路径给出最合适的缓存头建议。

本文标签： # 这事 # 越传 # 离谱