SPA 更新检测实战：确保用户及时获取单页应用最新版本

type

status

date

slug

summary

背景：SPA 的优势与更新挑战

单页应用 (Single Page Application, SPA) 因其流畅的用户体验和出色的性能而备受青睐。通过在客户端（浏览器）运行大量 JavaScript 并动态更新页面内容，SPA 避免了传统多页应用的整页刷新，显著提升了应用的响应速度。

然而，这种架构也带来了一个独特的挑战：版本更新的及时性。由于 SPA 的静态资源（HTML, CSS, JavaScript 文件）在首次加载后通常会被浏览器缓存（内存缓存或磁盘缓存），当服务端部署了新版本（例如，API 接口结构变更、功能更新、Bug 修复）后，用户可能仍在运行旧的、缓存中的前端代码。这可能导致功能异常、数据错误甚至应用崩溃，影响用户体验和业务逻辑。

核心问题：缓存导致的版本不同步

在传统多页应用中，用户每次导航通常都会从服务器请求最新的 HTML 页面，从而自然地获取到最新资源。但在 SPA 中，核心的 HTML (通常是 index.html) 和 JavaScript bundle 文件可能长时间驻留在浏览器缓存中。即使服务器上的文件已经更新，浏览器若判断缓存有效（例如，根据强缓存策略 Cache-Control: max-age），就不会去服务器请求新版本。

因此，我们需要一种机制来主动检测服务端是否发布了新版本，并在检测到更新时，友好地提示用户进行刷新，以加载最新的应用资源。

目标效果：实现用户更新提示

我们期望达到的效果是：当系统检测到后台部署了新版本后，能够给正在使用旧版本的用户弹出一个提示框，引导他们更新。

(示例图：更新提示弹窗)

这个弹窗可以使用 UI 库（如 Ant Design）轻松实现：

关键在于何时调用 showUpdateNotice()。下面介绍几种常用的客户端检测方案。

方案一：比较构建文件的 Script 标签 (基于 Hash)

核心思路: 现代前端构建工具（如 Webpack, Vite）通常会为打包后的 JavaScript 和 CSS 文件名添加内容哈希 (content hash)，例如 app.[hash].js。当文件内容改变时，哈希值也会改变。我们可以定期去服务器获取入口 HTML 文件 (index.html) 的内容，提取其中所有 <script> 标签的 src 属性（或整个标签字符串），与当前页面加载时记录的脚本信息进行对比。如果不一致，则说明有新版本部署了。

前提条件: 构建配置需要启用文件名哈希。

实现代码:

打印结果示例:(与原文相同，展示了检测到更新时新旧脚本集合的对比)

网络请求: 这种方案会定期请求入口 HTML 文件。如果服务器配置了协商缓存 (ETag/Last-Modified)，且文件未更新，服务器会返回 304 Not Modified，浏览器可能不会下载完整的 HTML 内容，从而节省带宽。但即使是 304，仍然会产生一次网络请求。

(与原文相同，展示了304响应的网络请求)

优缺点:

优点: 相对直观，直接对比了实际加载的脚本资源引用。

缺点:

需要定期请求并解析 HTML 文件，即使返回 304 也有请求开销。
HTML 解析（尤其用正则）可能不够健壮，易受 HTML 结构变化影响。
依赖构建工具生成带 Hash 的文件名。

方案二：比较 HTTP 缓存头 (ETag / Last-Modified)

核心思路: 利用 HTTP 协议的协商缓存机制。服务器通常会为静态资源（包括入口 index.html）生成 ETag (实体标签，通常是文件内容的哈希) 或 Last-Modified (最后修改时间) 响应头。我们可以定期向服务器请求入口 HTML 的头信息 (使用 HEAD 方法) 或带有特定缓存控制的 GET 请求，获取其当前的 ETag 或 Last-Modified 值，并与首次加载时记录的值进行比较。如果该值发生变化，则表明服务器上的文件已被更新。

实现代码:

ETag 打印结果示例:(与原文相同，展示了检测到更新时新旧 ETag 的对比)

优缺点: