applicationCache.status为1（CACHED）才表示当前版本缓存成功；0为未注册或解析失败，2为检查中，3为新版本就绪但未切换，4为废弃；现代浏览器已移除该API。
applicationCache.status 怎么看是不是缓存成功了
缓存是否成功，不能只看页面没报错，得主动查 applicationCache.status 的值。这个值是实时的整数，对应不同状态，比如 1（CACHED）才是真缓存完成，而 3（UPDATEREADY）只是新版本下载好了但还没切换——这时候刷新页面才会用新缓存，不算“已成功缓存当前版本”。
-
0（UNCACHED）：根本没注册 manifest，或解析失败，applicationCache对象都可能为null -
1（CACHED）：manifest 加载、资源全部缓存完毕，离线可直接用 -
2（CHECKING）：正在检查 manifest 是否有更新，此时页面仍走旧缓存 -
3（DOWNLOADED/UPDATEREADY）：新资源下完了，但没替换，要手动调swapCache()才生效 -
4（OBSOLETE）：manifest 文件被删或返回 404，整个缓存会被浏览器清除
监听 applicationCache 更新事件为什么总不触发
事件不触发，大概率是因为你没在 window.applicationCache 初始化完成前就绑定监听，或者页面根本没关联有效的 manifest。注意：applicationCache 是全局单例，但它的事件只对当前文档生效，且必须在 document.readyState === 'interactive' 或之后绑定才可靠。
- 不要在
DOMContentLoaded之前绑事件，否则可能错过cached或updateready - 确保
写对了路径，且服务器返回text/cache-manifestMIME 类型 -
checking事件只在有网络、且 manifest 文件本身有改动时触发；纯离线访问不会触发检查流程 - 常见误操作：把事件绑在
window上却忘了加applicationCache前缀，正确写法是window.applicationCache.addEventListener('cached', handler)
cache.manifest 文件里哪些行会导致缓存失败
manifest 文件看似简单，但几类写法会静默失败：资源 404、路径错误、跨域请求、MIME 类型不对，都会让整个缓存中止，状态卡在 0 或 2 不动。
- 所有
CACHE:下列出的资源必须能被浏览器 200 获取，任一 404 就导致缓存中断，且不提示 - 相对路径以 manifest 文件所在目录为基准，不是 HTML 页面路径；比如
manifest在/static/app.manifest，那CACHE: js/main.js实际请求的是/static/js/main.js -
NETWORK:和FALLBACK:区块里的路径也受同源限制，不能写跨域 URL（如https://api.example.com） - 服务器必须返回
Content-Type: text/cache-manifest，Nginx/Apache 都要显式配置，否则浏览器直接忽略 manifest
applicationCache 在现代浏览器里还能用吗
不能。Chrome 94+、Firefox 85+、Edge 94+ 已完全移除 applicationCache API，调用 window.applicationCache 会返回 undefined，相关事件和状态全失效。这不是兼容性问题，是标准废弃 —— W3C 早在 2016 年就标记为“obsolete”，现在唯一可行的离线方案是 Service Worker + Cache API。
立即学习“前端免费学习笔记（深入）”；
- 即使旧版浏览器还能跑，新项目绝不要从头接入；存量项目升级时，
applicationCache的降级逻辑没法优雅 fallback 到 Service Worker - 调试时看到
applicationCache.status === 0，先确认是不是浏览器根本不支持，而不是 manifest 写错了 - 很多线上教程还在讲 manifest，但实际部署时，Chrome DevTools 的 Application → Manifest 面板已经灰掉或显示 “No application manifest found”
真正要落地离线能力，得切到 Service Worker；而 applicationCache 现在只存在于遗留系统维护和某些内网老环境里，它的状态监听逻辑再细也没法绕过被删除的事实。
