HTML不应长期缓存，应设no-cache或max-age=0、must-revalidate；静态资源（JS/CSS/图片）须用内容哈希命名并配Cache-Control: public, max-age=31536000, immutable，确保HTML更新时资源同步生效。
HTML 本身不缓存静态文件，真正起作用的是 HTTP 缓存策略对 js、css、img
为什么给 HTML 加 Cache-Control: public, max-age=3600 反而让 JS/CSS 不更新
很多人误以为“缓存 HTML 就能缓存它引用的资源”，其实完全不是一回事。浏览器加载 index.html 后，会按里面写的 <script src="main.js"></script> 单独发起新请求——这些请求各自走自己的缓存逻辑。如果 main.js 响应头没设 Cache-Control，或设了但没带内容哈希，用户就可能一直用旧 JS，哪怕 HTML 已更新。
- HTML 缓存时间长（比如
max-age=3600），但 JS/CSS 缓存时间短或没设，会导致 HTML 新、资源旧，页面行为错乱 - JS/CSS 文件名不变（如始终叫
app.js），即使内容变了，浏览器仍可能复用缓存副本，因为 URL 没变 - 开发时本地起服务（如
python -m http.server）默认不发缓存头，容易误判“没缓存”——上线后 Nginx/Apache 配了缓存才暴露问题
静态文件必须带内容哈希，且 URL 与哈希强绑定
这是解决“改了代码用户看不到”的最可靠方式。哈希值来自文件内容，内容一变，URL 就变，浏览器自然当作全新资源请求。
- 构建工具（Webpack/Vite）默认开启
contenthash：输出类似main.a1b2c3.js，而非main.[hash].js（后者可能因入口变化而全量更新） - HTML 中的引用必须由构建过程自动注入，不能手写——否则哈希变了但 HTML 还引用旧名，404 或加载错版本
- CDN 场景下，也要确保源站响应头对带哈希的路径返回长期缓存（如
Cache-Control: public, max-age=31536000），否则 CDN 不会存
HTTP 响应头怎么配才不翻车
别依赖 ，它在 HTML 文件中完全无效；必须由服务器或 CDN 在 HTTP 响应头里设置。
-
js/css/font/img等静态资源：用Cache-Control: public, max-age=31536000, immutable（immutable告诉浏览器“这个 URL 永远不会变内容”，可跳过后续验证） -
index.html：必须用Cache-Control: no-cache或must-revalidate，让它每次检查是否更新（配合 ETag/Last-Modified） - 敏感页（如登录弹窗 HTML 片段）：用
no-store，彻底禁用缓存 - Apache 用户注意：
mod_expires和mod_headers都要启用，且ExpiresByType的优先级低于Header set Cache-Control，建议统一用后者
本地开发时如何验证缓存行为是否生效
靠肉眼看“刷新后快不快”毫无意义。真实验证得看 Network 面板里每个请求的 Size 列和 Status 列。
- 状态码是
200 (from memory cache)或200 (from disk cache)→ 走了强缓存 - 状态码是
304 Not Modified→ 走了协商缓存（ETag 匹配成功） - 状态码是
200且 Size 显示具体字节数 → 完全没缓存，每次都下载 - 右键某个 JS 请求 → “Copy” → “Copy response headers”，粘贴查看是否含
Cache-Control和值是否符合预期
最容易被忽略的一点：HTML 引用的资源路径是否真的随内容变化——很多团队只加了哈希，却忘了让构建流程把新哈希写进 HTML，结果缓存策略再完美也白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
