17370845950

HTML5 AppCache 缓存更新需修改 manifest 文件内容（如版本注释），并确保 Content-Type 正确；须调用 update() 并监听 updateready 事件后 swapCache()；但 AppCache 已被 Chrome 80+/Firefox 85+ 废弃，应迁移到 Service Worker。

修改 html5manifest 文件内容才能触发缓存更新

HTML5 Application Cache（manifest）不会因为页面 HTML 或 JS 文件变了就自动更新缓存，它只认 .appcache（或任意后缀但 MIME 为 text/cache-manifest）文件本身是否发生变化。哪怕你只在文件末尾加一个空格，浏览器都会当作新版本重新下载所有资源。

所以「改版本号」本质是「改 manifest 文件内容」，不是改某个注释字段就能生效——浏览器不解析注释，只做字节级比对。

• 必须确保服务器返回的 manifest 文件实际内容发生了变化（哪怕只是 # v2.1 → # v2.2）
• 确保响应头包含 Content-Type: text/cache-manifest，否则浏览器直接忽略
• 不能仅靠刷新页面触发更新；需监听 window.applicationCache 的 updateready 事件并手动 swapCache()

applicationCache.update() 必须显式调用才检查更新

页面加载时浏览器会自动检查 manifest 是否有变，但这个检查只发生在首次访问或硬刷新（Ctrl+F5）时。日常刷新（F5）不会重新验证。要主动触发检查，必须调用 update() 方法。

if (window.applicationCache) {
  window.applicationCache.update(); // 发起更新检查
  window.applicationCache.addEventListener('updateready', function() {
    if (window.applicationCache.status === window.applicationCache.UPDATEREADY) {
      window.applicationCache.swapCache(); // 切换到新缓存
      location.reload(); // 重载以使用新资源
    }
  });
}

• update() 是异步的，不会立即下载，只会发起一次 HEAD/GET 请求比对 manifest
• 如果服务端没正确设置 ETag 或 Last-Modified，可能始终返回 304，导致更新失败
• swapCache() 只在 updateready 状态下有效，其他状态调用无效

常见失效场景：服务端缓存、CDN、本地调试干扰

即使 manifest 内容改了，仍可能卡在旧缓存，原因往往不在前端代码，而在网络链路：

• CDN 缓存了 manifest 文件（例如 Cloudflare 默认缓存 .appcache），需手动 purge 或设置缓存策略为 no-cache
• 本地开发服务器（如 live-server、webpack-dev-server）默认不支持 text/cache-manifest MIME 类型，需显式配置
• Chrome 80+ 已废弃 AppCache，Firefox 85+ 也已移除，manifest 缓存实际已不可用于新项目
• 若用 HTTPS，但 manifest 文件被 HTTP 中间设备劫持重写（如某些企业代理），会导致签名不匹配而静默失败

替代方案比「修 manifest」更值得投入时间

AppCache 存在单点故障、更新逻辑反直觉、无法细粒度控制等根本缺陷。现代标准已全面转向 Service Worker：

• 用 navigator.serviceWorker.register('sw.js') 替代 manifest 属性
• 更新逻辑由开发者完全控制：skipWaiting() + clients.claim() 可实现立即生效
• 支持动态缓存、网络优先/缓存优先策略、后台同步等
• 所有现代浏览器均支持，且无 MIME 类型或路径后缀限制

如果你还在维护老项目中的 manifest，重点应放在迁移路径上，而不是反复调试版本号写法——那只是在给一个已被标准废弃的机制打补丁。