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-manifestMIME 类型，需显式配置 - Chrome 80+ 已废弃 AppCache，Firefox 85+ 也已移除，manifest 缓存实际已不可用于新项目
- 若用 HTTPS，但 manifest 文件被 HTTP 中间设备劫持重写（如某些企业代理），会导致签名不匹配而静默失败
替代方案比「修 manifest」更值得投入时间
AppCache 存在单点故障、更新逻辑反直觉、无法细粒度控制等根本缺陷。现代标准已全面转向 Service Worker：
- 用
navigator.serviceWorker.register('sw.js')替代manifest属性 - 更新逻辑由开发者完全控制：
skipWaiting()+clients.claim()可实现立即生效 - 支持动态缓存、网络优先/缓存优先策略、后台同步等
- 所有现代浏览器均支持，且无 MIME 类型或路径后缀限制
如果你还在维护老项目中的 manifest，重点应放在迁移路径上，而不是反复调试版本号写法——那只是在给一个已被标准废弃的机制打补丁。
