17370845950

HTML5 manifest 已被 Chrome 95、Firefox 85、Safari 16.4 彻底移除，调用 window.applicationCache 报错，.appcache 文件被忽略；HTML4 无离线能力，仅依赖不可控的 HTTP 缓存；Service Worker 是唯一标准支持的可靠离线方案，需 HTTPS 环境*册并手动管理缓存与请求。

HTML5 的 manifest 文件已废弃，现代浏览器全部停止支持；HTML4 本身不支持离线访问，所谓“离线”只能靠浏览器缓存机制临时生效，不可控、不可靠。

为什么 manifest 现在完全不能用了

从 Chrome 95、Firefox 85、Safari 16.4 起，manifest（即 html manifest="xxx.appcache"）已被彻底移除。调用 window.applicationCache 会直接报 ReferenceError，且页面不会触发任何缓存行为。

• 即使你写了正确的 .appcache 文件，浏览器也完全忽略它
• NETWORK:、CACHE:、FALLBACK: 这些节名已无实际语义
• 开发工具里再也看不到 “Application → Manifest” 面板
• Service Worker 是唯一被标准支持的离线方案，manifest 没有替代配置项

HTML4 页面能“离线打开”吗

不能真正离线访问。所谓“离线能打开”，只是因为浏览器对 HTML/CSS/JS 做了常规 HTTP 缓存（比如 Cache-Control: max-age=3600），用户刷新或重访时可能从磁盘加载资源——但这不是设计出来的离线能力，而是巧合。

• 没有清单机制，无法声明哪些资源必须缓存、哪些必须联网
• 无法拦截网络请求、无法 fallback 到本地页面（比如 404 时显示 offline.html）
• 清空浏览器缓存后，页面立即无法加载
• HTTP 缓存策略由服务器控制，HTML4 页面自身无权声明缓存意图

想实现可靠离线，现在必须用 Service Worker

这是目前唯一标准、跨浏览器（Chrome/Firefox/Edge/Safari 16.4+）支持的方案。核心是注册一个 JS 脚本，在其中监听 install 和 fetch 事件。

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered'))
    .catch(err => console.error('SW reg failed:', err));
}

对应 sw.js 示例（简化版）：

const CACHE_NAME = 'v1';
const urlsToCache = [
  '/',
  '/index.html',
  '/style.css',
  '/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))
  );
});

• 必须通过 HTTPS（或 localhost）才能注册 Service Worker
• caches.open() 和 caches.match() 是关键 API，替代了 manifest 的声明式缓存
• 需要手动处理更新逻辑（比如清旧缓存、跳过等待），不像 manifest 那样自动比对版本号

真正可靠的离线体验，不在文件写法里，而在是否主动控制请求流和缓存生命周期——这点很容易被忽略：很多人以为只要把 manifest 换成 sw.js 就万事大吉，结果没处理好缓存失效或 fallback 逻辑，反而比原来更不稳定。