根本原因是HTTP缓存机制导致浏览器复用旧index.html；需服务端配置正确响应头、资源文件名哈希、前端版本检测三者协同。
index.html 为什么改了用户还看不到新内容
根本原因不是浏览器“不更新”，而是它按 HTTP 缓存规则，把旧的 index.html 当作有效资源复用了。现代浏览器对 HTML 文件默认走协商缓存（Cache-Control: no-cache 或 max-age=0），但前提是服务器真返回了这些头——如果 Nginx/Apache 没配，或 CDN 把 /index.html 当静态文件缓存了 24 小时，那用户就卡在旧版本里，连刷新都不触发新请求。
服务端加响应头是最有效的控制点
客户端所有技巧（如 location.reload(true)、meta 标签、手动 Ctrl+Shift+R）都不可靠：Chrome 93+ 已废弃 reload(true) 参数；<meta http-equiv="Cache-Control"> 对外部 JS/CSS 完全无效，且被 Chrome/Firefox 忽略多年。
- Nginx 配置中必须显式匹配
.html后缀，并设置三要素：Cache-Control: no-cache, must-revalidate、Pragma: no-cache、Expires: 0 - Apache 的
.htaccess要用<Files "*.html">块，不能只写Header set在全局 - CDN（如 Cloudflare、阿里云 DCDN）需单独配置路径缓存规则，把
/index.html加入“绕过缓存”或“缓存 TTL=0”白名单——否则服务器头会被 CDN 覆盖 - 用
curl -I https://yoursite.com/index.html验证响应头是否生效，重点看Cache-Control字段值，不是看有没有这个 header
JS/CSS 等资源必须和 HTML 解耦缓存
HTML 不缓存，但 JS/CSS 却设了 max-age=31536000（一年），这是最常见翻车点：你改了 app.js 并部署，但浏览器根本不发请求，因为缓存没过期。解决方式不是禁掉 JS/CSS 缓存，而是让它“可失效”：
- 构建工具（Webpack/Vite）必须开启文件名哈希，生成类似
main.a1b2c3.js，并在index.html中自动注入该路径——这样 URL 变了，缓存自然失效 - 手写项目可用查询参数，但必须保证每次部署都更新参数值，例如
app.js?v=20261009，不能写死成v=1 - 避免混用：不要一边用哈希文件名，一边又在 link/script 标签里硬写
?v=1，会导致两次加载同一资源 - Service Worker 若已注册，必须在 install 阶段主动清理旧 cache，否则即使 HTML 和 JS 都更新了，SW 仍会返回缓存里的旧文件
用户无感更新需要前端主动检测
光靠缓存策略无法覆盖“用户开页后长期不刷新”的场景。SPA 页面一旦加载完成，后续路由跳转不触发 HTML 重载，旧 JS 逻辑就一直跑着。
立即学习“前端免费学习笔记（深入）”；
- 在
index.html中内联一个版本标识，如<script>window.__BUILD_HASH__ = "a1b2c3";</script> - 运行时定时 fetch 一个轻量接口（如
/version.json），比对 hash 是否变化 - 发现不一致时，提示用户刷新，或调用
location.reload()——注意不要用location.assign()重定向，那会绕过浏览器的协商缓存机制 - 该方案依赖服务端能稳定提供版本信息，且不能把
/version.json自己也缓存太久（建议设为max-age=60）
真正难处理的不是“怎么清缓存”，而是“怎么让浏览器在不打扰用户的情况下，知道该换新版”。服务端头是底线，资源哈希是基础，前端检测是补丁——三层缺一不可，漏掉任何一层，都会在某个用户身上复现“明明部署了，他却看不到”的问题。
