HTML必须设为no-cache或max-age=0，因其是页面入口，若被强缓存，浏览器将沿用旧HTML请求已删除的带hash资源路径，导致404和语法错误。
HTML 缓存机制不是浏览器“想缓存就缓存”，而是浏览器严格按响应头执行的一套确定性逻辑。你看到的“白屏”“404 报错”“刷新还是旧版”，几乎全是 Cache-Control、ETag、URL 是否带哈希这几个字段共同作用的结果，和浏览器版本、用户操作方式关系极小。
为什么 HTML 必须设为 no-cache 或 max-age=0
HTML 是整个页面的入口和调度中心：它决定了要加载哪个 main.a1b2c3.js、哪个 style.f4e5d6.css。一旦 HTML 被强缓存（比如 Cache-Control: public, max-age=3600），浏览器就会在 1 小时内无视服务端任何更新，继续用旧 HTML 去请求旧资源路径——而这些路径在发版后早已被删掉，服务器返回 404 HTML 页面，浏览器把它当 JS 执行，于是报 Uncaught SyntaxError: Unexpected token '。
- 即使你用构建工具生成了带 contenthash 的 JS/CSS 文件名，只要 HTML 本身可被长期缓存，整个缓存解耦就失效
-
no-cache不代表“不缓存”，而是每次都要走协商缓存（发If-None-Match，等服务器回304），既保证新鲜性，又省带宽 -
must-revalidate必须和no-cache或短max-age配合使用，否则过期后浏览器可能直接用陈旧副本（尤其在弱网或离线时）
meta http-equiv="Cache-Control" 在现代浏览器中基本无效
你在 <head> 里写 <meta http-equiv="Cache-Control" content="no-cache">，Chrome、Firefox、Edge 都会忽略。这个标签只在部分老旧 WebView（如某些 Android 系统内置浏览器）中起作用，不能当作真实缓存控制手段。
- 真正生效的只有 HTTP 响应头里的
Cache-Control - 服务端必须在返回 HTML 时带上该 header，例如 Nginx 中：
add_header Cache-Control "no-cache, must-revalidate"; - 如果你用的是 SSR 框架（如 Next.js、Nuxt），需确认其渲染中间件是否覆盖了你设置的缓存头
F5 刷新 vs 地址栏回车：浏览器对 HTML 的验证逻辑不同
用户按 F5 和直接在地址栏敲回车，浏览器对 HTML 的处理策略是两套逻辑：
立即学习“前端免费学习笔记（深入）”；
- 地址栏回车：优先走强缓存；如果 HTML 响应头是
Cache-Control: no-cache，则一定发协商请求（带If-None-Match或If-Modified-Since） - F5 刷新：强制跳过强缓存，直接进入协商缓存流程；哪怕 HTML 还在
max-age有效期内，也会发验证请求 - Ctrl+Shift+R（硬刷新）：跳过所有本地缓存，连协商都不走，强制发全新请求（但服务器仍可能返回 304，取决于它是否真做了校验）
这意味着，线上出问题时，单靠让用户“F5 一下”并不能解决问题——如果服务端没配 ETag 或 Last-Modified，或者 CDN 层吞掉了这些 header，F5 后依然可能拿到过期 HTML。
HTML 缓存错误最常被忽略的点：CDN 和反向代理层的 header 覆盖
你明明在源站配置了 Cache-Control: no-cache，但 Network 面板里看到的 HTML 响应头却是 Cache-Control: public, max-age=3600——大概率是 CDN（如 Cloudflare、阿里云 CDN）或 Nginx 反向代理在中间改写了 header。
- Cloudflare 默认会对 HTML 启用“标准缓存”，需手动关掉 HTML 缓存或设置 Page Rule 强制 bypass
- Nginx 的
proxy_cache如果没配proxy_ignore_headers Cache-Control;，就会把源站的no-cache当作无效而自行缓存 - 检查最终响应头，一定要看「Actual Request Headers」而非「Response Headers」里的原始配置，中间层修改往往悄无声息
缓存链路上任何一个环节擅自加缓存，都会让 HTML 失去时效性。比起调优 JS 加载顺序或压缩图片，先确保 HTML 每次都能正确验证，才是发版稳定的底线。
