Meta标签的Cache-Control对离线访问完全无效，manifest属性已被主流浏览器彻底移除，真正起作用的是Service Worker的install+fetch闭环，需满足HTTPS、根目录部署、skipWaiting与clients.claim等生效条件。
meta标签的Cache-Control对离线访问完全无效
加 <meta http-equiv="Cache-Control" content="max-age=3600"> 不会让页面离线可用。它只影响浏览器对当前页面的内存或磁盘缓存策略，不触发任何资源预加载，也不改变 fetch 行为。断网后，HTML 文件本身可能被缓存，但其中 <script src="app.js">、<link href="style.css"> 仍会发起网络请求——404 或超时，页面白屏或功能缺失。
manifest属性已被浏览器彻底移除
manifest="cache.appcache" 在 Chrome 95+、Firefox 85+、Safari 16.4+ 中已无任何作用。即使服务器返回正确的 Content-Type: text/cache-manifest，DevTools 的 Application 面板也不会显示 Manifest 标签，navigator.applicationCache 为 undefined，控制台也静默不报错。这不是配置问题，是代码逻辑被直接删掉了。
- 所有主流浏览器在 2026 年已全面移除 AppCache 实现
- 哪怕你用 Electron 旧版或定制内核，也仅限极少数封闭环境，且更新不可靠（改了 JS 却忘了改 manifest 注释，缓存永不更新）
- 不存在“兼容 fallback”：没有轻量级平替方案，只有 Service Worker
真正起作用的是 Service Worker 的 install + fetch 闭环
离线能力依赖两个不可拆分的环节：install 事件中调用 cache.addAll() 预加载资源，fetch 事件中按需匹配并返回缓存。缺一不可。
-
cache.addAll(['/', '/index.html', '/style.css', '/app.js'])必须用绝对路径，且列表中任一资源 404 或响应头含Cache-Control: no-store，整个缓存操作就会失败，Worker 卡在 installing 状态 -
fetch里不能只写caches.match(event.request)—— 这会把 POST 请求、带 credentials 的 API 调用也塞进缓存，导致登录态失效或表单静默失败 - 正确做法是用
event.request.destination === 'document'识别 HTML 页面请求，其余静态资源可缓存，API 接口应走网络兜底
最容易被忽略的生效条件
Service Worker 不是注册完就立刻离线可用。它要经历注册 → install → waiting → active 四个状态，首次访问页面时注册成功，但缓存逻辑只对**下一次访问**生效；若想立即生效，必须在 waiting 状态下调用 skipWaiting()，并在 activate 中调用 clients.claim()。
立即学习“前端免费学习笔记（深入）”；
另外，sw.js 必须部署在根目录（或显式设置 scope），且页面必须通过 HTTPS（localhost 除外）提供——HTTP 域名下 navigator.serviceWorker 直接为 undefined，连注册都触发不了。
