AppCache manifest 已被所有主流浏览器弃用，2026年起完全移除支持；唯一可行替代方案是 Service Worker，需通过 serviceWorker.register('sw.js') 注册，并在 install/fetch 事件中精确控制缓存与请求拦截。
manifest 已被所有主流浏览器弃用，2026 年起 Chrome、Edge、Firefox 均不再支持，强行启用会静默失败——别再为新项目配置它，旧项目迁移 Service Worker 是唯一可行路径。
manifest 文件为什么突然不生效了
不是你配错了，是浏览器主动扔掉了这个机制。从 Chrome 95（2021 年底）开始，manifest 就被标记为 deprecated；到 2025 年中，所有稳定版浏览器已完全移除支持。即使 HTML 中还保留 manifest="cache.appcache"，控制台不会报错，但 Application 面板里看不到 Manifest 标签，缓存也不会写入。
- 访问页面时，
navigator.onLine可能仍返回true，但实际资源根本没进缓存 - 开发者工具的 Application → Manifest 面板彻底消失，换成空面板或直接报 “No manifests found”
- 服务器正确返回
Content-Type: text/cache-manifest也无济于事——解析逻辑已被删掉
如果你必须维护一个老项目，manifest 还能凑合用吗
极少数内网环境（如 Electron 旧版本、定制 Chromium 内核的工业终端）可能还保留支持，但需满足三个硬性条件：
-
manifest文件必须通过 HTTPS 或localhost提供，HTTP 域名下直接拒绝加载 - 第一行严格为
CACHE MANIFEST（不能多空格、不能小写、不能带 BOM） - 服务器必须返回
Content-Type: text/cache-manifest，Nginx/Apache 配置漏掉这一条，浏览器连请求都不会发
即便全部满足，更新行为依然不可靠：修改了 script.js 却忘了改 cache.appcache 里的注释版本号，用户永远看不到新代码。
替代方案只有 Service Worker，没有“轻量级平替”
想实现真正可控的离线访问，serviceWorker.register('sw.js') 是当前唯一标准路径。它不像 manifest 那样声明式“一键缓存”，但换来的是精确控制：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 可区分静态资源（
cache.addAll()）与 API 响应（cache.put()） - 能按 URL 模式匹配缓存（比如所有
/api/请求走网络，带v=参数的 JS 走缓存） - 更新时可通过
skipWaiting()+clients.claim()立即生效，不用等用户关掉所有标签页
注意：sw.js 必须放在网站根目录（或显式指定 scope），且首次注册必须在用户交互（如点击）后触发，否则会被浏览器拦截。
最容易被忽略的坑：缓存清理和调试闭环
Service Worker 缓存比 manifest 更难“清干净”。开发时常见问题：
- 改了
sw.js但页面还在用旧版本 —— 手动在 Application → Service Workers 面板点 “Skip waiting” - 缓存里塞了旧 CSS 却没删，导致样式错乱 —— 在
activate事件里调用caches.delete('old-cache-name') - 离线测试时发现页面白屏 —— 检查
fetch事件里是否漏写了event.respondWith()，没包裹会导致请求直接失败
真正上线前，务必在隐身窗口 + 离线模式下完整走一遍核心流程：首次加载 → 关闭网络 → 刷新 → 交互操作 → 恢复网络 → 检查更新是否触发。任何一环断掉，用户就会卡在 loading 或 404。
