问题

Web端版本更新弹窗实现 这篇文章里的方案有没有什么问题？有更好的方案吗？

结论

这篇文章的方向是对的：
对“低频版本更新提醒”来说，轮询一个轻量版本文件 + 检测到变化后提示刷新，确实是一个成本低、容易落地的思路。

但按文中的 demo 直接实现，会有几个明显问题；如果想让它在真实项目里更稳，建议把“当前页面版本”“远端最新版本”和“缓存策略”三件事拆开处理。

主要问题

1. 首次访问会被误判成“发现新版本”

来源代码里，currentVersion 来自 localStorage，若没有就默认为 0.0.0，然后马上去拉 /version.json 做比较：

这会导致：

  • 用户第一次打开站点时，本来拿到的已经是最新页面
  • 但本地没有 version
  • 程序把它当作 0.0.0
  • 一比较就弹“发现新版本”

也就是说，这个 demo 没有真正区分“当前页面本身的版本”和“本地存过的上次版本”。

2. window.location.reload(true) 不能跨浏览器保证“强制刷新”

文中的 demo 用了：

但 MDN 说明里提到，reload() 的 forceGet 参数是非标准的，true 只在 Firefox 支持，其他浏览器不能指望它帮你跳过缓存。
参考：

所以“调用 location.reload(true) 就能强制拿到最新资源”这件事，在现代浏览器里并不稳。

3. version.json 用时间戳防缓存虽然有效，但比较粗暴

文中方案通过给 version.json 拼 ?t=Date.now() 来避免缓存：

这能工作，但副作用是：

  • 每次请求都会变成一个全新 URL
  • 浏览器和 CDN 都很难复用缓存
  • 无法优雅利用 ETag / Last-Modified

如果只是想确保版本文件每次都向源站校验，通常更好的做法是：

  • 给版本文件单独配 Cache-Control: no-cache 或 no-store
  • 或在 fetch 里显式设置 cache: 'no-store'

参考：

4. “稍后提醒”缺少节流，可能反复骚扰用户

点击“稍后提醒”后只是把弹窗移除：

但 currentVersion 仍然旧，定时器也没停；下一次轮询仍会继续弹出。
这不一定是 bug，但用户体验通常不够好，至少应该有：

  • 本次会话内不再提醒
  • 或 30 分钟 / 1 天后再提醒

5. setInterval 可能导致请求重叠

如果网络慢、接口偶发卡顿，新的轮询可能在上一次还没结束时又发出。
对版本检查这种简单任务，通常用“一次请求结束后再 setTimeout 下一次”会更稳。

更稳的改法

方案 A：保留轮询思路，但修正版本模型

这是我最推荐的“简单、够用、容易上线”的版本。

核心改法：

  1. 在构建时把当前页面版本写进页面本身
    • 例如注入 window.__APP_VERSION__ = '2026.04.14-1'
    • 或写入 <meta name="app-version" content="...">
  2. 远端继续提供 /version.json
    • 只包含当前最新版本号
  3. 轮询时比较
    • 当前页面版本 __APP_VERSION__
    • 远端版本 version.json
  4. 首次访问不要弹
    • 因为当前页版本本来就明确了，不需要靠 localStorage 猜
  5. 刷新是否生效靠缓存策略保证，不靠 reload(true)
    • index.html / 入口 HTML：Cache-Control: no-cache, must-revalidate
    • JS/CSS：文件名带 hash，长期缓存

这其实和文中第二部分提到的“HTML 不强缓存 + 静态资源带 hash”是一致的，只是 demo 代码没有把这层做完整。

方案 B：如果项目已经用 Service Worker，就走 SW 更新流

如果你的项目本身已经是 PWA 或用了 Service Worker，那么更好的方案往往不是自己轮询 version.json，而是直接监听 Service Worker 更新状态：

  • 新 SW 安装完成
  • 进入 waiting
  • 页面提示“发现新版本，点击刷新”
  • 用户确认后让新 SW 接管，再刷新页面

参考：

这个方案的优点是：

  • 更新信号更接近真实资源更新
  • 不用额外维护一套 version.json
  • 更适合已经接入 SW 的现代前端项目

方案 C：多标签页场景下，把检查逻辑集中化

如果用户经常同时开多个标签页，最好不要每个 tab 都各自轮询。
可以考虑：

  • 一个 tab 负责检查
  • 用 BroadcastChannel 或 storage 事件同步给其他 tab

这样可以减少重复请求，也避免多个页面同时弹窗。

推荐结论

如果是普通 Web 项目，没有 Service Worker、也不想加后端实时通道，我推荐的最佳实践是：

  1. 继续用轮询
  2. 当前页版本来自构建注入，不来自 localStorage
  3. 远端最新版本来自 /version.json 或构建清单
  4. 入口 HTML 不强缓存，静态资源走 hash
  5. 只用 location.reload() 触发刷新，不依赖 reload(true)
  6. 给“稍后提醒”加会话级或时间级节流

一句话判断

这篇文章的架构选择没有大问题，问题主要出在 demo 的几个实现细节上。
如果把“版本来源”和“缓存更新”这两层修正好，这套方案仍然是一个很实用的基础版实现。

相关页面