这条提醒一出——91大事件，关于缓存设置的说法 | 原来大家都误会了…如果属实，那就太刺激了

前言：一条关于“缓存设置”的提醒突然在技术圈炸开锅，配合耸动的标题和“91大事件”的讨论热度，很多人开始怀疑自己的网站是不是随时会被缓存搞垮。冷静下来看看，很多流言其实源自对缓存机制的误解。下面把常见误区拆开讲清楚，并给出实战可用的建议，帮你把缓存变成加速利器，而不是隐患。

误区一：把资源设置为很长的 max-age 就万无一失 真相：长时间缓存对静态资源（版本化的 JS/CSS/图片）确实能带来巨大性能提升，但前提是你对版本控制有严格策略（文件名或 querystring 改版本）。对 API 响应或频繁变更的页面使用长缓存，会导致用户看到陈旧数据。做法：静态资源用 max-age=31536000 + immutable 并且通过构建工具打上哈希；动态资源仍需短缓存或协商缓存（ETag/Last-Modified）。

误区二：ETag 可以代替 Cache-Control 真相：ETag 是协商缓存的一部分，用于判断资源是否变化以决定是否返回 304。Cache-Control 指定缓存策略和缓存时长。两者不是互斥，通常最好同时设置：Cache-Control 控制是否和多久缓存，ETag/Last-Modified 提供变更检测。

误区三：有 CDN 就不用考虑浏览器缓存 真相：CDN 主要负责边缘缓存和传输优化，但浏览器缓存策略仍由响应头决定。正确做法是让 CDN 缓存并加速静态资源，同时通过合适的 Cache-Control 让浏览器也缓存，双层加速才能发挥最大效果。

误区四：query string 一律会阻止缓存 真相：缓存行为依赖于服务端和 CDN 配置。许多 CDN 默认会缓存带 query 的资源，但某些配置或中间件会把带 query 的请求视为动态。解决方案是对需要缓存的带版本 query 的资源明确设置缓存规则，或者优先用指纹化文件名。

误区五：Service Worker 会覆盖一切缓存规则 真相：Service Worker 可以控制网络请求和缓存策略，但它的行为受你编写的脚本逻辑约束。错误配置的 SW 确实可能导致旧资源长期存在，正确的做法是实现明确的缓存更新策略、版本检查和激活流程。

关键头信息模板（常见场景）

• 静态版本化资源（CDN + 浏览器）：Cache-Control: public, max-age=31536000, immutable
• 短期缓存的 API（允许协商缓存）：Cache-Control: public, max-age=60, must-revalidate；并配合 ETag/Last-Modified
• 私人或敏感数据：Cache-Control: private, no-store, no-cache, must-revalidate
• 需要立即不缓存：Cache-Control: no-store

排查工具与方法（快速动作）

• 浏览器 DevTools Network 面板：查看响应头、缓存命中情况
• curl -I https://example.com/path：快速查看返回头
• Lighthouse / PageSpeed：识别未发挥缓存潜力的资源
• CDN 控制台查看边缘与源站命中率，必要时手动清理或配置自动失效策略

实操检查清单（五步） 1) 静态资源是否指纹化（filename.hash.ext）？没有就先改。 2) 重要响应是否含有合适的 Cache-Control？根据更新频率分别设置。 3) API 是否需要协商缓存（ETag/Last-Modified）？开启后测试 304 行为。 4) CDN 与浏览器缓存策略是否一致？避免两端相互抵触。 5) 如果使用 Service Worker，有没有实现版本切换和缓存清理逻辑？

本文标签： # 这条 # 提醒 # 一出