manifest 属性已废弃，chrome 94 起彻底移除支持；service worker 是唯一可行的离线缓存方案，需 https 环境下用 navigator.serviceworker.register() 早期注册，注意生命周期、缓存策略与调试要点。
manifest attribute 已被弃用，别再配 manifest 属性了
Chrome 94 起彻底移除了对 manifest 属性的支持，Firefox 和 Safari 更早就不支持。如果你还在 HTML 标签里写 ，页面不会报错，但缓存行为完全失效——浏览器直接忽略它。这个机制从诞生起就存在兼容性差、更新策略僵硬、无法细粒度控制等问题，不是“用法不对”，而是标准层面已废弃。
Service Worker 是唯一可行的离线缓存替代方案
它不是“另一个选项”，而是当前 Web 平台唯一能真正接管网络请求、实现自定义缓存逻辑的机制。关键在于：它必须通过 JavaScript 注册，且只在 HTTPS（或 localhost）环境下生效。
-
navigator.serviceWorker.register()必须在页面加载早期调用（比如<script></script>放在底部），延迟注册可能导致首屏资源不被拦截 - 注册的 JS 文件（如
sw.js）不能带查询参数（sw.js?v=1会被视为不同脚本，导致重复注册或更新失败） - 首次注册后，Service Worker 生命周期独立于页面：关闭标签页不影响其运行，但刷新页面时可能仍运行旧版，需手动触发
skipWaiting()
缓存策略要按资源类型拆开写，别一股脑 cache.addAll()
静态资源（JS/CSS/字体）适合版本化缓存；HTML 建议网络优先 + 失败回退；API 接口通常不该进 Cache Storage，而应走网络或用 Cache-Control 配合 HTTP 缓存。
self.addEventListener('fetch', event => {
const url = new URL(event.request.url);
if (url.origin === location.origin) {
if (url.pathname.endsWith('.html')) {
// HTML：先试网络，断网时返回缓存的 fallback 页面
event.respondWith(
fetch(event.request).catch(() => caches.match('/offline.html'))
);
} else if (/\.(js|css|png|jpg|woff2)$/.test(url.pathname)) {
// 静态资源：缓存优先，后台静默更新
event.respondWith(caches.match(event.request).then(r => r || fetch(event.request)));
event.waitUntil(updateStaticCache()); // 单独函数更新缓存
}
}
});
调试 Service Worker 极容易掉坑，重点盯这三个地方
Chrome DevTools 的 Application > Service Workers 面板是唯一可信来源，不要依赖 console.log —— 它默认不显示在页面 console 里，得切到 Service Worker 上下文。
- 注册失败时，检查控制台是否报
Failed to register a ServiceWorker，常见原因是sw.js返回 404 或 MIME 类型不是text/javascript - 更新不生效？看面板里是否有 “waiting” 状态 —— 这说明新 SW 已安装但没激活，需调用
self.skipWaiting()并监听controllerchange - 缓存没命中？用
caches.open('my-cache').then(cache => cache.keys())在 Console 里手动查 key，注意 URL 是否带 hash、trailing slash 等细微差异
缓存键的精确匹配比想象中更敏感，一个斜杠、大小写、查询参数缺失都会导致 miss。别假设“路径一样就肯定能取到”。
