HTML缓存本身不拖慢速度，问题在于配置不当导致旧内容、资源不更新或白屏；关键在Cache-Control指令选择、资源版本控制及服务端响应头准确设置。
HTML 缓存本身不拖慢页面速度，但配置不当会直接导致用户看到旧内容、资源不更新、甚至白屏——关键不在“用不用”，而在“怎么配”和“配给谁”。
Cache-Control 指令选错，页面就卡在旧版本上
很多人把 no-cache 当成“禁止缓存”，结果发现页面改了 CSS 却没生效。其实它只是跳过强缓存，仍会走协商缓存（发请求问服务器“有没有变”），而如果服务器没返回 ETag 或 Last-Modified，浏览器可能直接复用旧响应。
-
no-store才是真·不存：适合登录页、支付确认页等敏感页面，每次强制重载 -
public, max-age=31536000, immutable适合带哈希名的 JS/CSS：告诉浏览器“这文件永不变”，连 F5 都不发验证请求 - HTML 文件本身建议用
max-age=300或no-cache：防止模板更新后用户刷不出新结构
静态资源没做版本控制，缓存再久也没用
你给 style.css 设置了 max-age=1y，但每次发布都覆盖同名文件，用户浏览器根本不知道该更新——它只认 URL，URL 不变，缓存就永远不换。
- 构建时生成带内容哈希的文件名，比如
main.a1b2c3d4.js，HTML 中引用它，URL 变了缓存自然失效 - 避免靠
?v=1.2.3查询参数“骗”缓存：CDN 和某些代理可能忽略查询参数 - 图片、字体这类不常改但体积大的资源，可放心设长缓存 + 哈希名
HTTP/2 下的缓存策略要重新评估
HTTP/2 支持多路复用，单个连接并发请求，这时“少发请求”的收益下降，而“缓存粒度太粗”反而成问题。比如一个 bundle.js 里混了通用逻辑和页面专属代码，某一页改了，全量 JS 都得重下。
- 拆包比以前更重要：按路由或功能分 chunk，让变更影响范围最小
- 慎用
immutable：它依赖资源内容绝对不变，但 Webpack 等打包工具的 hash 可能受构建环境影响（如时间戳、路径） - 服务端推送（Server Push）已被主流放弃，别在 Nginx 或 Apache 里配它，反而干扰缓存逻辑
最易被忽略的一点：缓存头必须由服务器真实响应发出， 在 HTML 文档内只对 HTML 本身生效，且不被所有浏览器严格遵守；JS/CSS/图片等资源的缓存行为完全取决于它们各自 HTTP 响应头——这个边界一旦混淆，排查就绕弯路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
