我把关键点核对了一遍，新91视频：关于缓存设置的说法｜其实答案很简单但没人说…？不排除还有后续
我把关键点核对了一遍，新91视频：关于缓存设置的说法｜其实答案很简单但没人说…？不排除还有后续
刚看完新91的视频，里面对缓存设置的讨论引起了不少争议，评论区也很热闹。为了把信息弄清楚，我把视频里的每个关键点逐一核对、补充了常见误区，并给出一套可直接上手的建议配置。结论很直接：缓存策略并不神秘，关键在于分类、版本管理和基于内容设定不同的TTL（Time To Live），但很多人忽略了这些基础做法。
视频中的主要说法与核对结果
- 说法一：把所有静态资源都设长缓存就万无一失。核对结果：不完全对。静态资源（如图片、字体、打包后的 JS/CSS）可以长缓存，但前提是文件名具备版本控制（fingerprint/哈希）。否则用户会长期拿到旧资源。
- 说法二：HTML 页面也应长缓存以提高速度。核对结果：不建议直接这样做。HTML 本质上是容易变动的入口页，长缓存会导致用户拿到过时页面。可采用短 TTL 或者 no-cache + ETag，以在必要时快速更新。
- 说法三：CDN 自动处理一切缓存问题。核对结果：CDN 很强，但它只会按照你设置的缓存头或 CDN 配置缓存。源站头部设置、缓存击穿、缓存失效策略都需要仔细设计。
- 说法四：缓存越长越能省资源。核对结果：在确保更新可控（通过版本化）前提下是这样，但如果没有版本化机制，长缓存会带来更新延迟、调试困难和用户体验问题。
常见误区与容易被忽略的点
- 把 query string 当成版本控制：许多 CDNs 和浏览器对 query string 的处理不一致。更稳妥的做法是把版本号直接放到文件名，如 app.abc123.js。
- 忽视 immutable：对于真不变的资源，Cache-Control: immutable 能告诉浏览器即便用户强制刷新也不必要重新请求，减少不必要的网络请求。
- API 与动态内容混用静态策略：API 响应通常要么不缓存，要么短缓存，尤其是涉及用户隐私或实时性的数据。
- 忽略错误场景的处理：在源站失败时，CDN 的 stale-if-error、stale-while-revalidate 可以减少全站不可用的影响，但要考虑数据一致性风险。
一套简单、实用的缓存策略（可直接参考）
- 静态资源（打包后的 JS/CSS、字体、图片等）：
- 文件名使用哈希版本（如 app.abc123.js）
- Cache-Control: public, max-age=31536000, immutable
- CDN 层可长期缓存并开启压缩、合并策略
- HTML 页面（可变的入口页）：
- Cache-Control: no-cache, must-revalidate 或 Cache-Control: public, max-age=0, s-maxage=60
- 同时使用 ETag 或 Last-Modified 以便条件请求（304）减少传输量
- API 接口及用户相关页面：
- Cache-Control: private, max-age=0, no-store / no-cache（视数据敏感性而定）
- 对于可缓存的非敏感 API（如公共数据），使用短 TTL 并结合 stale-while-revalidate 策略
- 图片类大资源（CDN 场景下）：
- 若版本化文件名：Cache-Control: public, max-age=31536000, immutable
- 若非版本化：选择短 TTL，并考虑使用 CDN 的自动刷新/清除机制
- 离线与 PWA（Service Worker）：
- 简单资源优先用文件名版本化并由 service worker 做缓存策略
- 注意更新策略（比如采用 “network-first” 还是 “cache-first”）需根据页面类型决定
实际操作示例（常见 header 参考）
- 版本化静态资源：
- Cache-Control: public, max-age=31536000, immutable
- HTML：
- Cache-Control: no-cache, must-revalidate
- 或者：Cache-Control: public, max-age=0, s-maxage=60
- API（敏感数据）：
- Cache-Control: private, no-store
如何做版本管理与上线流程更顺畅
- 构建时生成带哈希的文件名，CI/CD 将引用替换到 HTML 模板或模板系统里。
- 上线后仅通过更新文件名就能实现“缓存更新（cache busting）”，无须主动清理 CDN。
- 对于必须即时更新的情况，使用 CDN 的 API 清除指定文件缓存或配置较短的 s-maxage。
何时考虑更复杂的策略
- 高并发且对实时性敏感的应用（金融、竞拍类）需要更严格的缓存隔离与短 TTL。
- 内容分发到全球时，需在不同区域做回源与缓存规则权衡，避免某地频繁击穿源站。
- 遇到缓存一致性问题，监控与回滚机制比一味延长 TTL 更可靠。
结语：其实答案很简单，但没人把基础说清 把各种资源分门别类、用版本化文件名、对 HTML 保持短缓存并用条件请求检测更新，这几步就能解决绝大多数缓存问题。剩下的就是根据具体业务权衡一致性与性能。新91的视频触及了关键点，但在实践细节上需要补充——这正是我把关键点核对并整理成这篇文章的出发点。不排除后续会根据新技术和真实案例再做深入更新，欢迎在评论里提你遇到的具体场景，我们可以把策略细化成可复制的配置片段。