manifest属性在现代HTML中已完全失效，Chrome 93、Firefox 95、Safari 16.4起彻底移除AppCache，使用<html manifest="app.manifest">将静默失效；替代方案必须用Service Worker+Cache API。
manifest 属性在现代 HTML 中已完全失效
HTML5 的 manifest 属性（用于声明 Application Cache，即 AppCache）自 Chrome 93、Firefox 95、Safari 16.4 起已被彻底移除，所有主流浏览器均不再支持。试图使用 <html manifest="app.manifest"> 不会触发缓存，也不会报错，但整个机制静默失效——这是最危险的情况：你以为缓存生效了，实际资源全走网络。
为什么 AppCache 被废弃而不是升级
AppCache 存在根本性设计缺陷，不是小修小补能解决的：
-
manifest文件更新后，页面需**第二次访问**才加载新资源（首次仍用旧缓存），导致部署后用户看到陈旧 UI - 离线时若
NETWORK:段声明不全，整个页面白屏（无降级 fallback 机制） - 缓存更新逻辑与 HTTP 缓存冲突，开发者无法控制优先级和生命周期
- 不支持按需缓存、增量更新、版本原子切换等现代 PWA 基础能力
替代方案必须用 Service Worker + Cache API
当前唯一标准且可行的离线缓存路径是 Service Worker 配合 Cache 接口。关键点不是“怎么写”，而是“怎么避免踩坑”：
- 注册 Service Worker 必须在 HTTPS 环境下（本地
localhost除外），否则navigator.serviceWorker.register()直接拒绝 - 缓存策略需显式区分：静态资源（
install事件中caches.open().addAll()）、动态请求（fetch事件中手动cache.put()或cache.match()） - 版本升级必须修改 SW 脚本文件内容（哪怕加个空格），否则浏览器认为“没变化”，不会触发
install和activate - 不要依赖
cache.addAll()的原子性——它失败时会回滚全部，建议用循环 +cache.put()并捕获单个请求错误
self.addEventListener('install', e => {
e.waitUntil(
caches.open('v1').then(cache =>
fetch('/manifest.json').then(r => r.json()).then(manifest => {
// 手动逐个缓存，避免 addAll 因单个失败而全盘崩溃
return Promise.all(
manifest.resources.map(url =>
fetch(url).then(r => cache.put(url, r))
)
);
})
)
);
});
检查是否还在误用 manifest 的方法
很多老项目残留 manifest 属性却误以为“PWA 已启用”，实际连 Service Worker 都没注册。快速验证：
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Application → Manifest 标签页：若显示 “No manifest detected”，说明
manifest属性已被忽略（不是找不到文件，是浏览器压根不解析它） - Application → Service Workers 标签页：若无注册记录，或状态为 “Waiting” / “Redundant”，说明 SW 未正确激活
- 禁用网络后刷新页面：如果白屏或报
net::ERR_INTERNET_DISCONNECTED，证明没走缓存——AppCache 失效且 SW 未接管
真正要花时间的地方，从来不是写几行缓存代码，而是理解 Service Worker 的生命周期如何与页面导航、fetch 时机、缓存命名空间交织在一起。一个没处理好 activate 事件中 caches.delete() 的旧版本缓存，可能让用户卡在半年前的 JS 里。
