HTML5 的 Application Cache(manifest)机制已被主流浏览器废弃,缓存失败主因是技术淘汰而非配置错误;需改用 Service Worker + Cache API 或 Workbox 实现现代离线能力。
HTML5 本身不“安装”,所谓“安装 HTML5 后缓存失败”实际是指基于 Application Cache(即 manifest)的离线缓存机制配置或运行出错——而这个机制在现代浏览器中已被废弃,Chrome 94+、Firefox 85+、Safari 16.4+ 均已彻底移除支持。所以,如果你在新项目中遇到“缓存失败”,大概率不是配置问题,而是技术路线已失效。
这是最常见且最容易被忽略的硬性门槛。浏览器只认 text/cache-manifest 类型的响应头,哪怕文件内容完全正确,只要服务器返回的是 text/plain 或 application/octet-stream,就会直接报错 “清单提取失败(-1)”。
.htaccess 或 mime.types 中添加 AddType text/cache-manifest .appcache 或 AddType text/cache-manifest .manifest
types { text/cache-manifest appcache; }
http.server:需自定义 handler,原生 SimpleHTTPServer 不支持,推荐改用 python -m http.server --bind 127.0.0.1:8000 并配合 serve 工具或轻量 Node 服务(如 http-server -c-1)file:// 协议)必然失败——AppCache 要求 HTTP/HTTPS 协议
EST 文件格式错误:空格、换行、路径全都是雷Manifest 解析极其脆弱,任何格式偏差都会导致整个缓存流程中断,且错误静默(控制台可能只报 -1,不提示哪一行错)。
CACHE MANIFEST 必须是文件第一行,前面不能有 BOM、空行、注释或空格\r\n 后的不可见空格)Scripts/script.js 和 scripts/script.js 是两个资源header("Location:") 或重定向逻辑),它们无法被缓存,且会阻断后续所有资源下载http://code.jquery.com/...),除非服务器明确允许 CORS 且 manifest 本身也托管在同一域下很多教程教你在 mobileinit 里绑定 window.applicationCache 事件,但这仅适用于 jQuery Mobile 早期版本,且前提是页面已加载 jQuery Mobile 库——纯 HTML5 项目根本不存在该事件。
标签中(非 DOMReady),且确保 DOM 尚未渲染完成前就注册:swapCache() 不会自动刷新页面,必须手动 location.reload();否则用户看到的仍是旧缓存document.location = 'xxx' 类跳转极其敏感,会导致缓存中止,需包裹 setTimeout 延迟执行AppCache 设计存在根本缺陷:缓存更新逻辑反直觉(更新 manifest 才触发全量重下)、无细粒度控制、强制全站缓存、不支持条件缓存、与 Service Worker 不兼容。所有主流浏览器已将其标记为 Deprecated 并最终移除。
Service Worker + Cache API,它支持按需缓存、版本化控制、网络优先/缓存优先策略、后台同步等Workbox(Google 官方封装库),几行配置即可生成健壮缓存策略Web App Manifest(manifest.json)实现“添加到主屏幕”和基础启动体验,但它不负责资源缓存真正关键的不是“怎么修 manifest”,而是确认你是否还在维护一个已被浏览器集体放弃的技术栈——如果是,迁移比调试更值得投入时间。