application cache（manifest）已全面废弃，导致白屏或加载失败；现代离线能力必须依赖 service worker + cache api，需正确实现 install、fetch、activate 三阶段逻辑，并注意作用域、html 缓存风险及 mime 干扰问题。
HTML 离线缓存机制本身对现代 Web 应用几乎没有实际影响——因为 Application Cache（即 manifest）在所有主流浏览器中已彻底移除或禁用，继续使用它会导致资源不更新、页面白屏、甚至注册失败。
为什么 manifest 会触发白屏或加载失败
Chrome 94+、Firefox 84+、Safari 16.4+ 已完全删除 Application Cache 支持。当 HTML 中仍写有 manifest="xxx.appcache" 时：
- 浏览器不再解析该属性，也不下载或更新任何缓存，但也不会报错（静默忽略）
- 若旧版缓存仍存在，部分 Safari/iOS WebKit 可能尝试加载过期资源，导致 JS 报错、CSS 不生效、
index.html404 - 服务器若错误配置了
text/cache-manifestMIME 类型，反而可能干扰其他资源的 Content-Type 推断
manifest 的缓存行为根本不可控
它不是“缓存策略”，而是一套僵化的声明式打包机制，和 HTTP 缓存头（如 Cache-Control）完全不兼容：
-
CACHE:下的文件一旦缓存，除非 manifest 文件内容变更，否则浏览器永不向服务器发请求验证——哪怕资源已被删，仍返回 200 from ServiceWorker 或 disk cache - 无法设置 per-resource 过期时间；无法区分 HTML 动态页和静态 JS；无法按网络状态切换策略
-
NETWORK:和FALLBACK:在现代多页应用（MPA/SPA）中极易失效，比如路由为/user/123时 fallback 规则不匹配路径前缀
真正起作用的是 Service Worker + Cache API
离线能力必须靠 serviceWorker.register('/sw.js') 启动，且逻辑需覆盖三个关键环节：
-
install：用
caches.open('v2')+cache.addAll([...])预缓存核心静态资源（注意：不能缓存带 query 的 URL，如/app.js?v=1.2） -
fetch：监听请求后，先
cache.match(req)，命中则返回；未命中则fetch(req)并cache.put()（可选），再返回响应 -
activate：用
caches.delete('v1')清理旧缓存，避免磁盘占用失控（尤其 PWA 安装后长期不更新）
示例中常见错误：event.waitUntil(caches.open(...)) 忘加 event.waitUntil 包裹，导致 install 失败却不报错；或在 fetch 中直接 return fetch(req) 而不处理 reject，断网时整个页面卡死。
HTML 文件本身不能被“离线缓存”而不带来风险
你不能安全地把 index.html 放进 cache.addAll 并期望它永远可用——因为 HTML 通常含动态内容（服务端渲染、CSR 初始化脚本）、CSRF token、或依赖实时接口。正确做法是：
- 只缓存纯静态的壳页（如
/offline.html），并在 fetch 中对 HTML 请求做 fallback：若网络失败，return caches.match('/offline.html') - 对主入口 HTML 使用
Cache-Control: no-cache或max-age=0，强制每次校验 ETag，避免用户看到陈旧的导航菜单或权限提示 - 若必须缓存 HTML，需配合版本化路径（如
/v2/index.html）+ Service Worker 主动更新逻辑，成本远高于收益
最易被忽略的一点：Service Worker 的作用域（scope）默认是 sw.js 所在路径，若 sw.js 放在 /js/sw.js，它就无法控制根目录下的 /api/ 请求——必须注册时显式传入 {scope: '/'}。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
