最直接方案是轮询index.html并比对script标签src路径:用fetch加时间戳防缓存,DOMParser解析HTML后提取script[src]转Set做差集比较,间隔设5–10分钟,监听页面可见性暂停轮询,检测到变化后提示用户刷新而非自动重载。
浏览器不会自动告诉你页面更新了,必须自己加逻辑检测 HTML 内容变化,否则用户可能一直卡在旧版本里,直到手动强刷或清缓存。
核心是比对当前页面的 <script> 标签 src 是否和服务器最新 HTML 里的不一致。Webpack/Vite 打包后 JS 文件名带 hash,只要脚本路径变了,基本就代表有新版本。
/?timestamp=1744574220345)防止被浏览器或 CDN 缓存住DOMParser 解析返回的 HTML 字符串,再用 querySelectorAll('script[src]') 提取所有带 src 的脚本路径Set 后做差集比较,比字符串全文比对更稳定(避免注释、空格、换行等干扰)很多 Nginx 或 Node.js 中间层默认开启协商缓存,但返回 304 Not Modified 时,前端根本收不到新内容,自然无法触发更新判断。
200 和新响应体;如果看到 304,说明服务端没放行cache: 'no-cache',并手动加请求头 Cache-Control: no-cache
/index.html 单独配缓存策略为 no-store
用户切走标签页、最小化窗口、锁屏时继续发请求,既无意义又影响性能,尤其在移动端会明显增加耗电。
立即学习“前端免费学习笔记(深入)”;
document.hidden 变化,配合 visibilitychange 事件控制定时器启停setInterval 硬轮询;改用 setTimeout 链式调用,方便随时中断和重置window.applicationCache 在 Chrome 95+、Firefox 92+ 已彻底移除,且它只适用于老旧的 manifest 方案,和现代打包部署完全不兼容。
window.location.reload(true) 会丢掉表单输入、滚动位置、WebSocket 连接等上下文真正难的不是写几行 fetch,而是让检测逻辑在各种网络环境、CDN 配置、浏览器休眠策略下都可靠运行——尤其是那个看似无害的 304 响应,最容易被忽略,也最常导致“明明发版了,用户就是不更新”。