HTML不应长期缓存，应设no-cache或max-age=0、must-revalidate；静态资源（JS/CSS/图片）须用内容哈希命名并配Cache-Control: public, max-age=31536000, immutable，确保HTML更新时资源同步生效。

HTML 本身不缓存静态文件，真正起作用的是 HTTP 缓存策略对 js、css、

img</strong></p>

<H3>为什么给 HTML 加 <code>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 响应头怎么配才不翻车

别依赖 <meta http-equiv="Cache-Control">，它在 HTML 文件中完全无效；必须由服务器或 CDN 在 HTTP 响应头里设置。

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

立即学习“前端免费学习笔记（深入）”；

• 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，结果缓存策略再完美也白搭。