HTML manifest属性在2026年已完全失效，浏览器直接忽略该属性且不发起任何请求；Chrome 95+、Firefox 85+、Safari 16.4+均已移除支持，W3C标记为obsolete，唯一可行替代方案是Service Worker。
html manifest属性在2026年已完全失效
它不会报错，也不会触发任何缓存行为——浏览器直接跳过该属性，不发起对 .appcache 或 .manifest 文件的请求。Chrome 95+、Firefox 85+、Safari 16.4+ 均已移除 Application Cache 支持，W3C 标准中明确标记为 obsolete。你看到“还能跑”，大概率是本地开发服务器未刷新、用了旧版 Electron 内核，或误判了开发者工具里的缓存状态。
为什么删掉所有 manifest="" 是第一步
残留的 html manifest="cache.appcache" 会干扰调试判断，比如你在 Application 面板里看不到 manifest 选项卡，却还在怀疑“是不是 MIME 类型没配对”或“版本号没更新”。这不是配置问题，是功能本身不存在了：
- 服务器返回
text/cache-manifestMIME 类型？浏览器无视 -
CACHE MANIFEST开头、注释带版本号、路径全对？浏览器无视 - 页面在 localhost 下跑通？那只是巧合（比如 Service Worker 已生效，你误以为是 manifest 起作用）
替代方案只有 Service Worker，且必须满足硬性条件
想实现离线访问，navigator.serviceWorker.register('sw.js') 是唯一路径，但以下三点缺一不可：
- 页面必须通过
https://或http://localhost提供（file://协议注册必然失败） -
sw.js必须与页面同源，且路径为相对或绝对 URL（如/sw.js，不能是./sw.js） - 必须显式监听
install和fetch事件：仅cache.addAll()不够，不拦截fetch请求，离线时照样 404
旧项目迁移时最常漏掉的细节
很多人以为“先保留 manifest，等 SW 上线再删”，这会导致缓存策略混乱，甚至旧缓存污染新 SW 的 cache 名称。实际操作中容易被忽略的是：
立即学习“前端免费学习笔记（深入）”；
-
caches.delete()必须在activate阶段调用，否则旧 cache 名称（如v1）一直残留，新资源无法覆盖 -
cache.match(e.request)默认只匹配完整 URL，不自动处理 query 参数差异；若需忽略?v=123，得自己截取e.request.url.split('?')[0] - HTML 页面本身（
/或/index.html）必须显式加入cache.addAll()列表，否则离线打开首页直接失败
