在前端开发中,页面更新后用户仍在使用旧版本的情况十分常见。浏览器不会主动提示新版上线,因此开发者需要自行添加检测机制,识别HTML内容的变化。 最直接的方案是轮询 index.html,比对当前页面与服务器最新版本的 script 标签路径是否一致。尤其是Webpack、Vite这类打包工具,JS文
在前端开发中,页面更新后用户仍在使用旧版本的情况十分常见。浏览器不会主动提示新版上线,因此开发者需要自行添加检测机制,识别HTML内容的变化。

长期稳定更新的攒劲资源: >>>点此立即查看<<<
最直接的方案是轮询 index.html,比对当前页面与服务器最新版本的 script 标签路径是否一致。尤其是Webpack、Vite这类打包工具,JS文件名通常带hash值——只要脚本路径发生变化,基本意味着新版已发布。具体操作时,每次fetch请求可附带时间戳参数(如 /timestamp=1744574220345),防止浏览器或CDN缓存;拿到HTML字符串后使用 DOMParser 解析,再通过 querySelectorAll('script[src]') 提取所有带src属性的脚本路径;将这些路径存入 Set 进行差集比较,比全文比对更稳定(避免注释、空格、换行等干扰)。轮询间隔建议设为5到10分钟,太短浪费请求,太长则可能错过关键更新。
核心是比对当前页面 标签的 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 响应,最容易被忽略,也最常导致“明明发版了,用户就是不更新”的尴尬局面。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述