Chrome 94起彻底移除Application Cache支持，manifest文件必然失效；替代方案是Service Worker+Cache API，需HTTPS、正确注册、精准缓存路径，并验证激活状态与离线命中。
Chrome 94 起彻底移除了对 Application Cache（即 manifest）的支持，所有基于 cache.manifest 的离线方案在新版 Chrome 中必然失效，不是配置问题，是协议已被弃用。
为什么 manifest 文件不再起作用
Chrome 从 v94（2021 年 8 月发布）开始完全删除了 Application Cache API。访问含 html manifest="xxx.manifest" 的页面时，控制台会报错：
Failed to load resource: the server responded with a status of 404 (Not Found) The application cache feature is deprecated and will be removed in Chrome.
这不是本地设置或服务端 MIME 类型导致的临时问题，而是 Chromium 主动移除——Application Cache 因设计缺陷（缓存更新不透明、强制全量更新、与 Service Worker 冲突等）被 W3C 废弃多年，Chrome 是最后一个跟进的主流浏览器。
替代方案只能用 Service Worker + Cache API
现代离线能力必须基于 Service Worker，它支持精细控制缓存策略、版本管理、网络回退逻辑等。关键点：
立即学习“前端免费学习笔记（深入）”；
-
Service Worker必须通过 HTTPS（或localhost）注册，HTTP 站点无法启用 - 注册代码需放在主页面 JS 中：
navigator.serviceWorker.register('/sw.js') -
sw.js文件不能有 BOM，且响应头需包含Content-Type: application/javascript - 首次注册后刷新页面才生效；调试时建议勾选 DevTools → Application → Service Workers → “Update on reload”
一个最简缓存 HTML/CSS/JS 的 sw.js 示例：
const CACHE_NAME = 'my-site-v1';
const urlsToCache = [
'/',
'/index.html',
'/style.css',
'/app.js'
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open(CACHE_NAME)
.then(cache => cache.addAll(urlsToCache))
);
});
self.addEventListener('fetch', event => {
event.respondWith(
caches.match(event.request)
.then(response => response || fetch(event.request))
);
});
检查是否真正离线可用的实操步骤
光写好 sw.js 不代表离线就通了，必须验证三件事：
- 打开 DevTools → Application → Service Workers，确认状态为 “Activated” 且“Start URL”匹配你的入口页
- 点击 “Offline” 切换网络离线，再刷新页面——若仍能加载，说明资源确实进了 cache；若白屏或报 504，说明
caches.match()没命中，可能是 URL 路径不一致（比如带 query 参数、大小写差异） - 在 DevTools → Application → Cache Storage 中展开对应
CACHE_NAME，手动查看缓存的 key 是否包含你期望的文件（注意：fetch()默认不缓存跨域资源，CDN 上的 JS/CSS 需显式添加到urlsToCache或在fetch事件中拦截处理）
真正卡住人的地方往往不是语法，而是缓存生命周期和请求匹配规则——比如 /api/data.json 被缓存了，但实际请求的是 /api/data.json?t=123，后者根本不会命中；又比如 index.html 被缓存，但里面引用的 bundle.abc123.js 没进缓存列表，离线时就会 404。这些细节不逐条验证，很容易以为“已启用离线”，其实只有一半生效。
