HTML5 manifest 已被弃用，Service Worker + Cache API 是唯一可靠离线方案；manifest 缓存逻辑不透明、失败即全崩、无运行时控制，Chrome 94+ 等主流浏览器已移除支持。
HTML5 的
已被现代
浏览器
弃用，
不能用于新项目
。Chrome 从 94 版本起彻底移除支持，Firefox 和 Safari 更早停止维护。现在唯一可靠、标准且受全面支持的离线方案是
+
。
为什么 manifest.appcache 不再可用
Manifest 文件（
）依赖
标签的
属性，但该机制存在严重缺陷：
缓存更新逻辑不透明：浏览器只在 manifest 文件内容
字节
变化时触发更新，且更新发生在下次页面加载，用户始终看到旧资源
失败即全盘崩溃：任意一个资源 404 或网络中断，整个缓存失败，页面无法离线加载
缺乏运行时控制：无法按需缓存、无法区分静态资源与 API 响应、无法处理条件逻辑
所有主流浏览器已标记为
并移除实现 —— 检查
或访问
即可确认
用 Service Worker 实现真正可控的离线能力
Service Worker 是运行在浏览器后台的脚本，可拦截网络请求、管理缓存、推送通知。它必须通过 HTTPS（localhost 除外）部署，且需注册 + 安装 + 激活三步生效。
典型流程如下：
Comet AI 浏览器
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
下载
立即学习
“
前端免费学习笔记（深入）
”；
页面中调用
注册脚本（如
）
sw.
js
内监听
事件，用
预缓存核心资源
监听
事件，对匹配 URL 的请求优先返回
结果，未命中再发起网络请求并存入缓存
注意：首次访问不会立即离线生效，需刷新一次让 SW 完成激活
常见踩坑点和兼容性提醒
Service Worker 虽是标准方案，但实际落地仍有几个关键细节容易出错：
必须放在站点根目录（或通过
显式声明），否则无法控制子路径页面
注册代码要放在
或
后，避免 DOM 未就绪导致失败
开发阶段频繁修改 SW 时，浏览器可能保留旧版本，需手动
或勾选 DevTools → Application → Service Workers → 「Update on reload」
不支持 IE 和旧版 Edge；Android WebView 需 Chrome 55+；iOS Safari 自 11.3 起支持，但早期版本有 fetch 缓存 bug
不要在 SW 中使用
、
等 DOM 对象 —— 它运行在独立线程，无 DOM 访问权限
离线能力不是加个配置就能开箱即用的事。manifest 是历史包袱，Service Worker 才是现在进行时。缓存策略、版本升级、回滚机制、动态资源处理——这些都得自己写逻辑，没有银弹。
manifestService WorkerCache APIcache.manifesthtmlmanifestDeprecatednavigator.onLinechrome://flags/#enable-appcachenavigator.serviceWorker.register()/sw.jsinstallcache.addAll()fetchcache.match()/* 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))
);
});
sw.jsscopewindow.onloadDOMContentLoadedskip waitingdocumentwindow