HTML不能强缓存，必须用Cache-Control: no-cache, must-revalidate配合ETag协商验证，确保每次请求都校验最新性；静态资源则应采用内容哈希命名+public, max-age=31536000, immutable实现高效安全缓存。
HTML缓存不能只设 Cache-Control: max-age=31536000 就完事——它天然和安全冲突：缓存越久，页面越可能加载过期的 JS/CSS，而这些资源一旦被中间人篡改或 CDN 节点污染，就等于把 XSS 或恶意重定向直接塞进用户浏览器里。
为什么 HTML 不该用强缓存
HTML 是入口文件，它的内容决定后续所有资源加载路径和执行逻辑。如果 HTML 被强缓存（比如 Cache-Control: public, max-age=3600），用户刷新时可能拿到旧版 HTML，而新版 JS 已上线、旧版 HTML 仍引用未更新的 script 标签或内联脚本，导致功能错乱甚至执行残留的危险代码。
更关键的是：攻击者一旦劫持过一次 HTML 响应（比如通过不安全的 HTTP 重定向、Wi-Fi 中间人、被污染的 CDN 边缘节点），强缓存会让这个恶意版本在用户本地盘踞数小时甚至数天，浏览器根本不会重新校验。
- 强缓存绕过服务器校验，无法感知服务端是否已下线某个高危组件
- HTML 本身常含动态生成的 nonce、csp-hash、token 字段，缓存后这些值失效，CSP 策略形同虚设
- 部分老旧 CDN 或代理会错误地对 HTML 缓存并忽略
Vary头，导致移动端用户看到桌面版 HTML
协商缓存才是 HTML 的安全底线
必须让每次 HTML 请求都至少跟服务器做一次轻量级校验。核心是靠 Last-Modified 或 ETag 配合 Cache-Control: no-cache（注意：不是 no-store）。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
no-cache 表示“可用缓存，但每次用前必须验证”，浏览器会自动带上 If-Modified-Since 或 If-None-Match，服务端只需比对时间戳或哈希值，命中则返回 304 Not Modified —— 这个响应体为空、HTTP 头极小，网络开销几乎可忽略，却能确保 HTML 永远是最新的。
- 服务端生成
ETag时，建议基于 HTML 内容哈希（而非文件修改时间），避免因构建时间抖动导致无效缓存 - 务必设置
Vary: User-Agent, Accept-Encoding，防止移动端请求被桌面端缓存覆盖 - 若使用 SSR，
ETag应包含数据快照标识（如数据库版本号或内容指纹），而非纯模板哈希
静态资源与 HTML 必须分离缓存策略
JS/CSS/图片这类静态资源可以且应该用强缓存，但前提是它们的 URL 包含内容哈希（main.a1b2c3.js）。这样 HTML 文件哪怕每次都是新鲜的，也能精准加载对应版本的资源，既防篡改又保效率。
常见错误是把 HTML 和 JS 放在同一个缓存策略下：比如全站统一配 Cache-Control: public, max-age=86400，结果 HTML 更新了，用户浏览器还在用旧缓存里的 HTML，继续请求昨天的 main.js，而今天那个文件早已被新构建覆盖——404 或加载错版本。
- HTML：用
Cache-Control: no-cache, must-revalidate+ETag - JS/CSS/字体：用
Cache-Control: public, max-age=31536000, immutable（immutable告诉 Chrome 不要发条件请求） - 图片等二进制资源：同上，但需确认 CDN 支持
immutable，否则降级为max-age=31536000
真正难的不是配哪几个头，而是让整个构建、部署、CDN 刷新链条对齐：HTML 的 ETag 要反映真实内容变更，静态资源的哈希要稳定可预测，CDN 节点不能擅自覆盖 Vary 或忽略 no-cache。漏掉任何一环，安全或效率总有一边会塌。
