HTML5 Application Cache 已被主流浏览器废弃，因缓存逻辑不透明、全量失败机制、无法细粒度控制等固有缺陷；推荐使用 Service Worker + Cache API 实现可控离线能力。
HTML5 的离线应用机制（Application Cache）**已被现代浏览器废弃，不应在新项目中使用**。Chrome 从 95 版本起完全移除支持，Firefox 和 Safari 早已弃用。manifest 文件和 applicationCache API 不再可靠，也无法与 Service Worker 兼容。
为什么 manifest 文件现在基本失效
浏览器厂商统一转向更可控、更灵活的 Service Worker + Cache API 方案。manifest 存在固有缺陷：
- 缓存更新逻辑不透明：即使修改了资源，浏览器可能仍用旧缓存，且
cache update触发时机难预测 - 全部或全不缓存：一个文件失败，整个缓存失败，
FALLBACK段对动态路径支持极弱 - 无法细粒度控制请求（如按 method、header、query 区分缓存）
-
NETWORK段不支持通配符（*在部分浏览器中无效），导致白名单维护成本高
manifest 文件语法与常见错误
如果必须维护遗留系统，需注意以下配置细节：
- 文件必须以
CACHE MANIFEST开头，且首行不能有空格或 BOM - MIME 类型必须是
text/cache-manifest（Nginx/Apache 需显式配置，否则被忽略） - 路径全部为相对路径，相对于
manifest文件所在目录，不是 HTML 所在目录 -
CACHE段中列出的资源若返回非 2xx 状态码（如 404），整个缓存过程会静默失败 - 版本控制只能靠注释行变化（如
# v1.2.3），但浏览器只在 manifest 文件内容字节级变化时才触发更新
示例 app.manifest：
立即学习“前端免费学习笔记（深入）”；
CACHE MANIFEST # 2024-06-15-10:22CACHE: /index.html /css/app.css /js/main.js
NETWORK: /api/ /login
FALLBACK: / /offline.html
替代方案：用 Service Worker 实现真正可控的离线
这是当前唯一推荐路径。核心逻辑由三部分组成：
- 注册：在主页面 JS 中调用
navigator.serviceWorker.register() - 安装：监听
install事件，用cache.addAll()预缓存关键静态资源 - 拦截请求：在
fetch事件中，先查cache.match()，未命中再走网络，可自定义 fallback 行为
关键区别：你可以决定每个请求是否缓存、缓存多久、如何更新、是否跳过缓存——而 manifest 完全做不到。
离线能力的关键不在“有没有缓存”，而在“能否精确控制缓存生命周期和回退策略”。manifest 是黑盒，Service Worker 是白盒——这个差异决定了它无法被修复，只能被替换。
