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"></script>、<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,连注册都触发不了。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











