manifest属性已废弃，因chrome 94、firefox 85等主流浏览器陆续移除支持，w3c标记为obsolete；应改用service worker+cache api实现离线缓存，二者无任何关系。
HTML 中的 manifest 属性是已被废弃的离线缓存机制，现代项目中不应再使用。
为什么 manifest 属性现在不能用了
Chrome 94（2021年9月）起完全移除了对 manifest 属性的支持；Firefox 85（2021年1月）已禁用；Safari 从不支持。W3C 在 HTML5.2 中将其标记为“obsolete”，WHATWG HTML 标准中早已删除该特性。浏览器不再解析 ，也不会触发任何缓存行为。
常见错误现象包括：
- 页面加了
manifest属性但离线打不开，控制台无提示或只报Application Cache is deprecated - 本地测试时看似生效（旧版浏览器或 Electron 旧内核），上线后在用户设备上完全失效
- Service Worker 注册成功，但
manifest文件仍被服务器返回 200，造成冗余请求和混淆
cache.manifest 文件结构和陷阱
即使你看到老项目里还留着 cache.manifest 或 home.appcache，它也只对极少数遗留环境（如定制 Android WebView、老旧内网系统）有意义。它的语法本身有三类指令：
-
CACHE:后面列出的资源会被强制缓存（含 HTML 自身，必须显式写入） -
NETWORK:后面是白名单，表示“永远不缓存，必须联网获取”，支持通配符*，但部分旧浏览器对*解析不一致 -
FALLBACK:格式为/online.html /offline.html，仅当网络失败且资源未被缓存时才触发，实际兼容性差，多数情况不生效
容易踩的坑：
- 文件首行必须是
CACHE MANIFEST，大小写敏感，缺空格或拼错就整个失效 - 文件 MIME 类型必须是
text/cache-manifest，Nginx/Apache 若没配，浏览器直接忽略 - 每次更新缓存必须修改 manifest 文件内容（哪怕只加个注释），否则浏览器认为没变化，不会重新下载
替代方案：用 Service Worker + Cache API
所有需要离线能力的新项目，唯一可行路径是 Service Worker。它不依赖 HTML 属性，而是通过 JavaScript 控制缓存逻辑：
- 注册入口：
navigator.serviceWorker.register('/sw.js')，注意路径需与 scope 一致 - 缓存策略由开发者定义：可精确控制哪些请求走缓存、哪些走网络、哪些并行比对
- 支持动态缓存（如按路由、按请求头）、后台同步、推送通知等，
manifest完全做不到
最小可用示例（sw.js）：
self.addEventListener('install', e => {
e.waitUntil(
caches.open('v1').then(cache => cache.addAll([
'/',
'/index.html',
'/style.css',
'/app.js'
]))
);
});
注意：caches.open() 和 cache.addAll() 是异步操作，必须用 e.waitUntil() 确保 install 阶段完成，否则 SW 可能进入 waiting 状态卡住。
别把 manifest.json 和 manifest 属性搞混
当前 PWA 场景下常见的 manifest.json 是完全不同的东西——它是 Web App Manifest，用于定义图标、启动页、显示模式等安装体验，由 <link rel="manifest" href="/manifest.json"> 引入。它和已废弃的 manifest 属性、.appcache 文件没有任何关系，也不参与资源缓存。
Webpack 构建产物中的 manifest.json（如 webpack-manifest-plugin 输出）更是另一回事：它只是资源名映射表，供后端渲染时查 hash 文件名用，和离线能力无关。
真正容易被忽略的是：很多团队在迁移到 Service Worker 时，会忘记清理旧的 manifest 属性和服务器上的 .appcache 文件，导致代码冗余、HTTP 请求浪费、甚至干扰 SW 的 fetch 事件监听。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
