appcache 已被所有现代浏览器弃用，manifest 清单文件在 chrome、firefox、edge 110+ 中完全失效；service worker 是唯一可行的离线方案，需通过 https 注册，精确控制缓存与 fallback。
AppCache 已被所有现代浏览器弃用，manifest 清单文件（.appcache）在 Chrome、Firefox、Edge 110+ 中完全失效，无法触发任何缓存行为。想靠它支撑弱网下的在线工具运行，这条路已经走不通。
为什么 manifest 清单在当前环境下根本不起作用
浏览器不再解析 html 标签上的 manifest 属性，也不会发起对 .appcache 文件的请求。即使你配置了正确的 Content-Type: text/cache-manifest，DevTools 的 Network 面板里也看不到该文件被加载——它被直接忽略。
- Chrome 自 94 版起移除 AppCache API，110+ 彻底删除解析逻辑
- Firefox 于 2023 年底完全禁用，
applicationCache全局对象返回undefined - Safari 在 iOS 16.4 / macOS 13.3 后停止支持，且不提供降级警告
- 服务器返回 200 + 正确 MIME 也没用：没有浏览器会读它
Service Worker 是唯一可行的离线入口点
弱网下维持在线工具基本运行，必须用 Service Worker 拦截请求并返回缓存响应。它不依赖 HTML 属性，而是通过 JS 注册生效，且能精确控制每个资源的缓存策略和 fallback 行为。
- 注册必须在 HTTPS 或
localhost下进行，HTTP 站点无法启用 -
install阶段用caches.open('v2')预缓存关键静态资源（HTML、CSS、核心 JS、图标） -
fetch事件中不能只写caches.match(req)，必须兜底：未命中时返回/offline.html或内联 fallback 响应 - 带查询参数的请求（如
/api/status?v=123）需在匹配前 normalize URL，否则caches.match()查不到
弱网场景下容易被忽略的三个硬性约束
很多在线工具开发者以为“缓存了 HTML 就能离线打开”，实际落地时卡在以下三点：
-
index.html必须设Cache-Control: no-cache，否则浏览器可能跳过 SW，直接从 HTTP 缓存返回旧版 HTML —— 导致新 JS 被旧 HTML 加载而报错 - API 请求不能全塞进 cache，要区分：只读接口（如配置获取）可缓存；写操作（如表单提交）必须走
network-only或暂存 IndexedDB 待联网同步 - 缓存名必须随版本变更，例如从
v1改为v2；否则caches.open('v1')会复用旧缓存，新资源永远进不去
真正让弱网可用的不是“多缓一个文件”，而是明确哪些请求允许离线响应、哪些必须拒绝、哪些要排队重试——这些逻辑只能由 Service Worker 编排，manifest 文件连表达能力都没有。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
