Application Cache 已被主流浏览器废弃，离线功能由 ServiceWorker 实现；其需 HTTPS 或 localhost 环境、sw.js 在根路径或正确 scope、且需刷新两次才生效。
Application Cache 已被主流浏览器废弃，不能作为“离线缓存技术”的学习目标。你现在看到的“能离线”，99% 是 ServiceWorker 在工作，不是 manifest。
别花时间学怎么写 cache.appcache 文件——它在 Chrome 94+、Firefox 84+、Safari iOS 16.4+ 中已彻底不可用，调用 window.applicationCache 会直接报 undefined，监听事件全失效。
为什么 manifest 文件总不生效？
不是你代码写错，而是浏览器早就不理它了。常见“静默失败”现象包括：
-
manifest="app.appcache"属性写了，但 Network 面板里根本没发app.appcache请求 - 明明改了
CACHE MANIFEST文件内容，浏览器却没触发更新 - 控制台没报错，但离线刷新页面直接白屏或 404
这些都不是配置问题，是浏览器主动跳过了整个机制。检查方法很简单：'applicationCache' in window 返回 false，就说明当前环境根本不支持——不用查服务器 MIME 类型，也不用调 update()。
立即学习“前端免费学习笔记（深入）”；
真正该掌握的离线核心：ServiceWorker + caches API
现代离线能力靠的是 ServiceWorker 拦截请求 + caches.open() 管理资源。它和 Application Cache 有本质区别：
-
Application Cache是声明式、全局、粗粒度、无版本控制 -
ServiceWorker是编程式、可细粒度控制（按 URL、method、header）、支持增量更新、能 fallback 到网络、可结合IndexedDB存结构化数据
最小可用示例只需两步：
① 在主页面注册：navigator.serviceWorker.register('/sw.js')
② sw.js 里写缓存逻辑：
self.addEventListener('install', e => {
e.waitUntil(
caches.open('v1').then(cache => cache.addAll(['/index.html', '/style.css']))
);
});
self.addEventListener('fetch', e => {
e.respondWith(caches.match(e.request).then(r => r || fetch(e.request)));
});
开发时最容易忽略的三个硬性条件
ServiceWorker 不是加个文件就能跑，必须同时满足：
- 页面必须通过
https://或http://localhost访问（file://协议完全不支持） -
sw.js必须放在域名根路径下，或确保其scope覆盖到要控制的页面（比如注册时写navigator.serviceWorker.register('/assets/sw.js', {scope: '/'})） - 首次注册后，必须刷新两次才能生效：第一次注册并 install，第二次才进入 activate 并接管页面请求
少一个条件，self.skipWaiting() 和 clients.claim() 都救不回来。
真正复杂的不是写几行缓存代码，而是处理更新策略、版本迁移、API 请求兜底、以及和 IndexedDB 的协同——这些没法靠 manifest 注释里的 “# v2.1” 解决，得自己写逻辑。
