HTML5缓存清单更新技巧

HTML5的缓存清单（cache.manifest）机制看似简单，实则极其脆弱且早已被现代浏览器弃用：它要求清单文件字节级变更才能触发更新、对语法错误零容忍、依赖已废弃的`window.applicationCache` API（Chrome 94+/Firefox 85+已彻底移除），更会在开发中制造“强制刷新仍显示旧HTML”的迷惑行为；若你还在维护使用该技术的项目，请立即迁移到Service Worker + Cache API，并彻底清理残留的manifest属性与调用代码——否则一个空格、一行注释或一次MIME类型配置失误，都可能让用户永远卡在过期版本里。

修改 cache.manifest 文件后页面不更新？

浏览器不会因为清单文件内容变了就自动重新下载资源——它只在检测到 cache.manifest 文件的字节内容（包括注释、空格、换行）发生变化时，才触发更新流程。很多开发者改了资源路径或版本号，却忘了动清单本身。

实操建议：

• 每次修改缓存资源前，必须改动 cache.manifest 的某一行（比如加一句 # v20240521 或改一个空格）
• 确保服务器对 .manifest 后缀返回 text/cache-manifest MIME 类型，否则浏览器直接忽略该文件
• 用开发者工具的 Application → Manifest 面板确认“Last updated”时间是否变化，没变说明浏览器根本没拉新清单

window.applicationCache 已废弃，但旧项目还在用

Chrome 94+、Firefox 85+ 已完全移除 window.applicationCache 和相关事件（updateready、cached 等）。如果代码里还写着 applicationCache.update()，控制台会报 TypeError: Cannot read property 'update' of undefined，且整个离线逻辑静默失效。

实操建议：

• 不要试图 polyfill applicationCache——它已被标准彻底淘汰
• 若必须维持离线能力，应迁移到 Service Worker + Cache API，用 caches.open() 和 cache.addAll() 替代清单式缓存
• 检查构建产物中是否残留 manifest="cache.manifest" 属性，删掉它，否则 Chrome 仍会尝试加载并失败告警

强制刷新时资源仍走本地缓存？

即使清空浏览器缓存或按 Ctrl+F5，只要页面之前被 cache.manifest 缓存过，HTML 文件本身仍由应用缓存提供，导致你看到的永远是旧版 HTML —— 这不是 HTTP 缓存问题，是应用缓存的“接管”行为。

实操建议：

• 开发阶段可在地址栏输入 chrome://appcache-internals/（Chrome）或 about:cache?storage=appcache（Firefox）手动删除对应站点的全部应用缓存
• 上线前务必在清单文件的 CACHE: 段中包含当前 HTML 文件（如 index.html），否则它不会被缓存，也就无法离线访问
• 避免在 NETWORK: 段写 *，这会让所有未显式声明的请求绕过缓存，但也会让 index.html 失去离线能力

清单文件语法错误导致整个缓存失败

一个错位的空格、漏写的冒号、非法字符（如中文标点），都会让浏览器拒绝解析清单，表现为：Application 面板显示 “No application cache information for this page”，且所有离线资源不可用。

实操建议：

• 清单第一行必须是 CACHE MANIFEST（全大写，无空格，无 BOM）
• CACHE:、NETWORK:、FALLBACK: 这些关键字后必须跟英文冒号和换行，不能写成 CACHE : 或 CACHE: 后紧接路径
• 路径区分大小写，js/app.js 和 JS/app.js 在服务器上是两个文件，但清单里写错大小写会导致缓存失败

离线缓存的脆弱性不在代码多难写，而在于它依赖一套早已过时、容错极低、调试极难的机制。哪怕只是改了一个图标路径，也得同步动清单、清本地、验 MIME、查面板——漏一环，用户就卡在旧版本里出不来。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《HTML5缓存清单更新技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。