index.html总不更新是因为服务端将其设为长缓存（如max-age=31536000），浏览器直接从磁盘缓存返回旧版；解决核心是服务端配置Cache-Control: no-cache或no-store，并确保返回ETag/Last-Modified以支持校验，禁用meta标签和reload(true)等无效前端手段。
为什么 index.html 总是不更新？
浏览器对 index.html 的缓存策略比 JS/CSS 严格得多——它常被设为 Cache-Control: public, max-age=31536000（一年），哪怕你改了文件内容，只要 URL 没变、ETag/Last-Modified 没触发重验，就直接从磁盘缓存返回旧版本。
常见现象：部署新版本后，用户刷新页面仍看到旧 HTML；DevTools Network 面板里 index.html 状态码是 200 (from disk cache) 或 304，而非预期的 200。
怎么让 index.html 强制走网络请求？
核心思路不是“强制刷新页面”，而是让浏览器认为这个 HTML 是“不可缓存”或“已过期”的资源。关键在服务端响应头和构建时的处理：
- 把
index.html的Cache-Control设为no-cache（允许缓存但每次需校验）或no-store（完全不缓存），绝不能设max-age大于 0 - 确保服务器对
index.html返回ETag或Last-Modified，否则no-cache也无效（校验无依据） - 若用 Nginx，配置类似：
location = /index.html {<br> add_header Cache-Control "no-cache";<br>} - 若用 Vercel/Netlify，它们默认对
index.html做正确缓存控制；但若你手动上传静态文件且没配 header，就得自己补
meta http-equiv 和 document.location.reload(true) 为什么不管用？
这两个是前端常见误区：
立即学习“前端免费学习笔记（深入）”；
-
<meta http-equiv="Cache-Control" content="no-cache">完全无效——HTTP 响应头由服务器决定，meta标签只对部分老旧浏览器（如 IE）有弱作用，现代 Chrome/Firefox 忽略它 -
document.location.reload(true)（即location.reload(true)）在多数浏览器中已被忽略，Chrome 从 93 版本起彻底废弃该参数，实际等同于reload()，仍可能走缓存 - 用户手动
Ctrl+Shift+R或Cmd+Shift+R虽然能绕过缓存，但这不是可交付的解决方案
构建阶段加哈希或时间戳有用吗？
对 index.html 本身加哈希（如 index.a1b2c3.html）可行，但成本高：需要同步更新所有入口链接、CDN 配置、SEO 入口，且破坏语义化 URL。
更务实的做法是“HTML 内联资源哈希”+“HTML 不缓存”组合：
- Webpack/Vite 等工具默认给 JS/CSS 文件名加哈希（如
main.abc123.js），并在index.html中引用它 - 只要
index.html自身不缓存，每次请求都会拉取最新 HTML，从而加载到新哈希的 JS/CSS - 如果必须保留
index.htmlURL 不变，又想避免手动清 CDN 缓存，可在构建后调用 CDN 的 purge API（如 Cloudflare 的/purge_cache）清掉该路径
真正卡住人的往往不是“怎么刷新”，而是没意识到 index.html 的缓存行为独立于其他资源，且服务端 header 权重远高于前端任何 hack。别碰 meta，别信 reload(true)，盯死 Cache-Control 响应头和 ETag 是否生效。
