HTML的manifest属性仅存在于<html>标签且已于2026年彻底失效，浏览器解析时直接忽略；替代方案仅为Service Worker，需手动注册、缓存声明与fetch拦截。
HTML <link> 标签没有 manifest 属性——这是个常见误解，真正用的是 <html manifest="xxx.appcache">，而这个属性在 2026 年已完全失效。
manifest 属性根本不会被浏览器解析
你可能在旧文档里看到类似 <link rel="manifest" href="/manifest.json"> 的写法，但它和离线缓存无关：那是 PWA 的 Web App Manifest（用于图标、启动屏等），不是 Application Cache 的 manifest。而 HTML 的 manifest 属性只存在于 <html> 标签上，且自 Chrome 95、Firefox 85、Safari 16.4 起已被彻底移除。
- 浏览器在 HTML 解析阶段直接跳过
manifest属性，不发起任何请求，也不报错 - 开发者工具的 Application 面板中，“Manifest”选项卡已消失，只剩 Service Workers
- 即使服务器返回了正确的
text/cache-manifestMIME 类型，内容也会被静默忽略
所谓“缓存同步机制”已不存在
AppCache 曾有“检查 manifest 文件是否变更 → 触发更新 → 下载新资源 → 切换到新缓存”的流程，但这套机制依赖于浏览器对 manifest 属性和 .appcache 文件的主动识别与监听。现在它连入口都没了。
- 没有 manifest 文件加载，就没有版本比对，也就谈不上“同步”
- 旧项目若仍保留
<html manifest="cache.appcache">，只会干扰调试——你以为缓存没生效，其实是它压根没启动 - 服务器上继续配置
AddType text/cache-manifest .appcache不仅无效，还可能误导日志分析
替代方案只有 Service Worker，且必须显式控制 fetch
离线缓存现在只靠 navigator.serviceWorker.register('sw.js')，且它不自动缓存任何东西，所有行为都要手动写逻辑。
立即学习“前端免费学习笔记（深入）”；
- 必须在
install事件中调用caches.open().addAll()明确列出要缓存的路径 - 必须在
fetch事件中用event.respondWith()决定返回缓存还是发起网络请求 -
sw.js只能在 HTTPS 或http://localhost下注册；file://协议完全不支持 - 更新缓存需在
activate阶段调用caches.delete()清理旧 cache 名称，否则旧资源会一直残留
最容易被忽略的是：Service Worker 的缓存是“手动声明 + 手动拦截”，没有隐式规则，也没有 fallback 自动降级。哪怕只漏写一个 fetch 监听，那个请求就会直接失败——这和当年 AppCache 的“声明即生效”完全不同。
