HTML文件必须禁用强缓存，因其作为SPA入口决定JS/CSS哈希路径；若被缓存，浏览器不发起请求，新资源无法加载，导致白屏或功能异常。
HTML 文件本身必须禁用缓存，否则后续 JS/CSS 的哈希更新就完全失效——这是所有前端缓存问题的起点。
为什么 HTML 缓存是最大隐患
HTML 是资源加载的入口，它里面写的 <script src="main.a1b2c3.js"> 路径一旦被浏览器缓存，哪怕 JS 文件已更新、文件名也变了，用户打开的仍是旧 HTML，自然继续请求旧 JS。此时 Network 面板里会看到：index.html 状态码是 304 Not Modified 或 200 OK (from memory cache)，而它引用的 JS 却是 404 或老版本。
- 常见表现：改完代码重新构建部署，用户刷新后功能没变、控制台报
Uncaught ReferenceError、样式错乱 - 根本原因：服务器对
index.html返回了Cache-Control: max-age=3600或类似强缓存头 - 正确做法：所有 HTML 响应头必须包含
Cache-Control: no-cache, no-store, must-revalidate，或至少no-cache（触发协商缓存） - 注意：Nginx 默认配置可能对所有
.html文件统一加了expires 1h，需单独排除
如何快速验证是否 HTML 缓存惹的祸
不用猜，直接看 Network 面板里 index.html 的响应头和状态码：
- 打开 DevTools → Network → 刷新页面 → 找到
index.html请求 - 点开它，看 Response Headers 里是否有
Cache-Control或Expires - 看 Status 列：如果是
304或200 (from memory cache)，基本锁定问题 - 右键该请求 → “Open in new tab”，如果新开标签页显示的是旧内容，说明本地磁盘/内存缓存已固化
- 终极验证：用隐身窗口访问，若隐身模式下正常，100% 是缓存问题（优先清本地缓存再查服务端）
Nginx 配置中容易漏掉的 HTML 缓存陷阱
很多人只配了 /assets/ 目录长期缓存，却忘了把 index.html 单独拎出来禁用缓存。以下配置片段必须同时存在：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
location = /index.html {
add_header Cache-Control "no-cache, no-store, must-revalidate";
add_header Pragma "no-cache";
add_header Expires "0";
}
-
location = /index.html必须用精确匹配（=），不能写成location ~ \.html$，否则会误伤其他 HTML 页面 - 如果使用 Vue Router / React Router 的 history 模式，还要额外处理所有非资源路径回退到
index.html，这个 fallback 规则不能继承上面的缓存头，需显式覆盖 - CDN（如 Cloudflare）也会缓存 HTML，即使 Nginx 配对了，CDN 后台仍需设置 HTML 缓存规则为“Bypass”或“Cache Everything + Cache Level: Ignore Query String”并排除
index.html
构建工具与部署流程中的隐性缓存风险
Webpack/Vite 构建产物本身不带缓存逻辑，但部署环节常埋雷：
- 静态托管平台（如 GitHub Pages、Netlify、Vercel）默认对
.html文件启用短缓存（如 Netlify 默认max-age=600），需在_headers或netlify.toml中显式覆盖 - CI/CD 脚本若用
rsync -av同步，未加--delete，旧index.html可能残留服务器上，导致新旧混杂 - 某些 CMS 或模板系统（如 Dreamweaver 模板）生成的 HTML 会内联 JS/CSS，这种情况下哈希策略失效，只能靠服务端强制不缓存 HTML + 定期清理 CDN
- 本地开发时用
file://协议打开 HTML，Chrome 会无视大部分缓存头，造成“本地正常、上线异常”的假象，务必用http://localhost测试
真正难排查的不是“有没有缓存”，而是“哪一层缓存没被清除”——浏览器、CDN、反向代理、对象存储、甚至中间网络设备都可能插手。每次怀疑缓存问题，先确认 HTML 是否实时更新，再逐层向上检查缓存头和清除动作，比重写逻辑快得多。
