manifest缓存已废弃，现代浏览器完全移除支持，强行配置将静默忽略；唯一可行替代方案是service worker，需https或localhost下注册sw.js，并通过caches.open()和fetch事件精确控制离线缓存。
manifest 缓存已废弃，现代浏览器不再支持，强行配置只会失败或静默忽略。
如果你正尝试让网站“离线可用”，别再碰 cache.manifest —— Chrome 自 2019 年起彻底移除支持，Firefox 在 2023 年禁用，Safari 从未完整实现。现在所有主流浏览器都只认 Service Worker。
为什么 manifest 会失效
浏览器实际行为不是“不生效”，而是根本不会触发缓存流程：ApplicationCache API 已从标准中删除，window.applicationCache 返回 null，html manifest="xxx" 属性被完全忽略，开发者工具里连 Application > Manifest 面板都已消失。
检查是否还在用 manifest 的典型错误现象
-
Failed to load resource: net::ERR_FAILED且请求路径带.appcache或.manifest - 页面加了
manifest="cache.appcache"，但 Network 面板里看不到任何缓存资源条目 - 服务器返回了
text/cache-manifestMIME 类型，但浏览器 DevTools 中Application > Cache Storage为空 - 旧代码里还调用
applicationCache.swapCache()或监听updateready事件 —— 这些方法已报TypeError
替代方案：用 Service Worker 实现真正可控的离线缓存
这不是“升级写法”，而是唯一可行路径。关键点不在代码多寡，而在控制逻辑是否匹配真实需求：
- 必须部署在
HTTPS或localhost（生产环境无例外） -
sw.js必须放在域名根路径（如/sw.js），否则navigator.serviceWorker.register()会因 scope 限制失败 -
install阶段用caches.open('v1').then(cache => cache.addAll([...]))预缓存静态资源，但不要把整个/加进去 —— 会触发大量 404 -
fetch事件里优先cache.match(req)，未命中再fetch(req)，并可选cache.put()更新缓存 —— 这才是“按需缓存”的核心 - 每次更新
sw.js文件内容（哪怕只改一个空格），浏览器才会触发新版本 install；旧缓存不会自动清除，必须在activate里显式调用caches.delete('v0')
最容易被忽略的细节
缓存策略和资源路径强耦合：比如你缓存了 /index.html，但实际访问的是 /，而服务器返回的是 200 而非重定向，那么 cache.match() 就找不到对应 entry —— 因为 URL 不一致。这类问题不会报错，只会默默走网络，且难以定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
