HTML5 manifest 已被弃用，Service Worker + Cache API 是唯一可靠离线方案；manifest 缓存逻辑不透明、失败即全崩、无运行时控制，Chrome 94+ 等主流浏览器已移除支持。
HTML5 的 manifest 已被现代浏览器弃用，不能用于新项目。Chrome 从 94 版本起彻底移除支持，Firefox 和 Safari 更早停止维护。现在唯一可靠、标准且受全面支持的离线方案是 Service Worker + Cache API。
为什么 manifest.appcache 不再可用
Manifest 文件（cache.manifest）依赖 html 标签的 manifest 属性，但该机制存在严重缺陷：
- 缓存更新逻辑不透明：浏览器只在 manifest 文件内容字节变化时触发更新，且更新发生在下次页面加载，用户始终看到旧资源
- 失败即全盘崩溃：任意一个资源 404 或网络中断，整个缓存失败，页面无法离线加载
- 缺乏运行时控制：无法按需缓存、无法区分静态资源与 API 响应、无法处理条件逻辑
- 所有主流浏览器已标记为
Deprecated并移除实现 —— 检查navigator.onLine或访问chrome://flags/#enable-appcache即可确认
用 Service Worker 实现真正可控的离线能力
Service Worker 是运行在浏览器后台的脚本，可拦截网络请求、管理缓存、推送通知。它必须通过 HTTPS（localhost 除外）部署，且需注册 + 安装 + 激活三步生效。
典型流程如下：
立即学习“前端免费学习笔记（深入）”；
- 页面中调用
navigator.serviceWorker.register()注册脚本（如/sw.js） - sw.js 内监听
install事件，用cache.addAll()预缓存核心资源 - 监听
fetch事件，对匹配 URL 的请求优先返回cache.match()结果，未命中再发起网络请求并存入缓存 - 注意：首次访问不会立即离线生效，需刷新一次让 SW 完成激活
/* sw.js */ const CACHE_NAME = 'my-site-v1'; const urlsToCache = [ '/', '/index.html', '/styles/main.css', '/scripts/app.js' ];self.addEventListener('install', event => { event.waitUntil( caches.open(CACHE_NAME) .then(cache => cache.addAll(urlsToCache)) ); });
self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request) .then(response => response || fetch(event.request)) ); });
常见踩坑点和兼容性提醒
Service Worker 虽是标准方案，但实际落地仍有几个关键细节容易出错：
-
sw.js必须放在站点根目录（或通过scope显式声明），否则无法控制子路径页面 - 注册代码要放在
window.onload或DOMContentLoaded后，避免 DOM 未就绪导致失败 - 开发阶段频繁修改 SW 时，浏览器可能保留旧版本，需手动
skip waiting或勾选 DevTools → Application → Service Workers → 「Update on reload」 - 不支持 IE 和旧版 Edge；Android WebView 需 Chrome 55+；iOS Safari 自 11.3 起支持，但早期版本有 fetch 缓存 bug
- 不要在 SW 中使用
document、window等 DOM 对象 —— 它运行在独立线程，无 DOM 访问权限
离线能力不是加个配置就能开箱即用的事。manifest 是历史包袱，Service Worker 才是现在进行时。缓存策略、版本升级、回滚机制、动态资源处理——这些都得自己写逻辑，没有银弹。
