HTML缓存仅影响文件获取时机，不参与渲染过程；它只决定HTML字符串从网络下载还是本地读取，后续DOM构建、解析、JS执行等步骤完全不变。
HTML缓存不参与渲染过程，只影响文件获取时机
浏览器渲染页面的前提是拿到完整的 HTML 字符串，而缓存机制只决定这个字符串是从网络下载，还是从本地磁盘/内存读取——它本身不改变 DOM 构建逻辑、不加速解析、也不跳过任何渲染步骤。一旦 HTML 内容进入 parser 流程，后续行为完全由模板结构、脚本位置、CSS 加载状态决定。
常见错误现象：给 index.html 配了 Cache-Control: public, max-age=31536000，结果用户刷新后仍看到白屏 2 秒；或者缓存生效了，但首屏按钮点击无响应——问题根本不在缓存，而在缓存回来的 HTML 里引用了已失效的 main.abc123.js 或漏加 defer。
- 缓存命中时，HTML 文件加载耗时趋近于 0ms（内存缓存）或 ~20ms（磁盘缓存），但 parser blocking、CSSOM 构建、JS 执行等阶段照常发生
- 缓存未命中时，TTFB + 下载时间拉长首字节延迟，但若 HTML 结构干净，后续渲染可能反而更稳（比如避免了旧 JS 与新 DOM 的兼容问题）
- CDN 缓存 HTML 后，若其返回的响应头被覆盖（如 CDN 默认加了
max-age=60），会导致浏览器实际遵循的是 CDN 头而非源站头，调试时容易误判
缓存策略错配会放大渲染阻塞问题
HTML 缓存不是“越久越好”，而是要和它所加载的资源生命周期对齐。一个长期缓存的 HTML 文件，如果引用了未带哈希的 app.js，那用户哪怕刷新十次，加载的仍是同一份 JS——而这份 JS 可能早已被新版构建覆盖，导致 404 或执行异常。
使用场景差异直接决定风险等级：
立即学习“前端免费学习笔记（深入）”；
- 静态文档页（如 /about）：可设
Cache-Control: public, max-age=3600，但必须确保所有<script src="..."></script>和<link href="...">路径含 content hash - SSR 入口页（如 /dashboard）：必须用
no-cache或max-age=0, must-revalidate，否则用户可能卡在旧路由、旧表单 action、甚至过期的 CSRF token 里 - 登录页（/login）：应设
no-store，防止密码框被浏览器自动填充旧值，或敏感提示语被缓存展示
meta http-equiv="Cache-Control" 对渲染毫无作用
写在 里的 <meta http-equiv="Cache-Control" content="no-cache"> 在 Chrome、Firefox、Edge 中完全被忽略，既不会阻止缓存，也不会触发验证请求。它只在极少数老旧 WebView（如某些 Android 4.x 系统）中可能降级生效，属于无效配置。
真正控制 HTML 是否参与渲染链路起点的，只有服务端返回的 HTTP 响应头。检查是否生效的唯一方式是打开 DevTools → Network → 点击 index.html 请求 → 查看 Response Headers 中的 Cache-Control 值，同时留意 x-cache（Cloudflare）或 x-cdn-cache（阿里云）是否为 HIT。
- Nginx 示例：
location = /index.html { add_header Cache-Control "no-cache"; } - Express 示例：
res.set('Cache-Control', 'no-cache'); - 若用 Vite/Next/Nuxt 等框架，需确认其 SSR 或静态导出配置未覆盖你手动设置的响应头
HTML 缓存时间越长，对 JS/CSS 路径准确性的依赖越强
缓存本身不犯错，但它会把“路径错误”“哈希缺失”“资源未压缩”等问题固化下来。一个缓存了 24 小时的 index.html，如果引用了未加 hash 的 vendor.js，那这 24 小时内所有新用户都会加载到旧版 JS，哪怕你已上线修复 bug 的新构建。
这不是缓存该背的锅，而是构建产物与缓存策略没对齐的表现：
- Webpack 用户必须启用
contenthash替代hash，否则 CSS 改动也会导致 JS 文件名变更，破坏长期缓存 - Vite 默认开启 contentHash，但若你在
index.html中手写<script src="main.js"></script>而非通过import注入，则构建产出的哈希路径不会被自动替换 - 服务端启用 Gzip 或 Brotli 后，HTML 体积通常缩小 50%~70%，但若 CDN 层关闭了压缩，用户实际下载的仍是未压缩版本——缓存再快，也救不了大体积传输
最常被忽略的一点：HTML 缓存时间越长，你越需要确保每次部署都触发对应缓存失效，而不是靠 max-age 自然过期。否则，用户看到的永远是“上一次部署时的 HTML + 上上次部署时的 JS”。
