HTML5转APP能否离线取决于前端缓存策略而非打包工具选项；必须通过Service Worker主动缓存静态资源，并区分首屏、API、大文件等不同缓存策略，同时验证cache.addAll()成功及处理网络状态降级。
HTML5 转 APP 本身不自动支持离线使用，是否能离线取决于你用的打包工具、资源缓存策略和 Web 内容本身的离线能力。
WebView 容器是否支持离线取决于底层引擎
绝大多数 HTML5 打包方案（如 Cordova、Capacitor、Tauri、uni-app、HBuilderX）最终都依赖系统 WebView 或 Chromium 内核加载网页。这些内核本身不保存网络请求历史，也不会自动缓存整个站点 —— 换句话说，index.html 一丢，APP 就白屏。
- Android 低版本 WebView（如 Android 4.4）对
Service Worker和Cache API支持极差，离线能力基本不可用 - iOS WKWebView 从 iOS 11.3 起才稳定支持
Service Worker，且需手动启用allowsInlineMediaPlayback等配置才不会意外中断脚本 - Electron / Tauri 类桌面方案可直接读取本地
file://路径，天然“离线”，但无法用fetch()请求同源接口（CORS 限制），需改用fs.promises.readFile或后端代理
离线必须靠前端主动缓存资源
没有 manifest.json（已废弃）或 Service Worker，光靠打包工具勾选“离线模式”毫无意义。
-
Service Worker是目前唯一可靠的离线方案，需注册 + 安装 + 拦截fetch事件，缓存 HTML/JS/CSS/图片等静态资源 - 缓存策略要区分：首屏资源（
cache-first）、API 数据（network-firstfallback 到cache）、大文件（如视频，建议不进 SW，改用IndexedDB或原生存储） - uni-app 的
uni.getStorage、Capacitor 的Storage插件只能存键值对，不能替代资源缓存；它们适合存用户数据，不是离线网页本身 - 务必在
sw.js中添加skipWaiting()和clients.claim()，否则更新 SW 后旧页面仍走老缓存
打包工具的“离线设置”只是辅助，不是开关
像 HBuilderX 的“离线打包”、Cordova 的 cordova-plugin-advanced-http、Capacitor 的 capacitor.config.json 中的 server.androidScheme，都不等于“开启离线”。它们只解决路径访问或协议适配问题。
立即学习“前端免费学习笔记（深入）”；
- HBuilderX “离线打包”本质是把
www目录整体拷进 APK，让file:///android_asset/www/index.html可访问 —— 但若 JS 里写了fetch('https://api.example.com')，没网时照样失败 - Cordova 默认禁用
clearCache()，但不清缓存 ≠ 有离线能力；反而可能因缓存脏数据导致白屏 - Capacitor 的
webDir配置错路径（比如写成dist/web但实际输出是dist/h5），会导致 APP 启动即 404，看起来像“离线失败”
真正决定能否离线的，是你有没有为每个关键资源设计加载 fallback、有没有验证 navigator.onLine 后降级 UI、有没有在 install 事件里 cache.addAll() 成功 —— 而不是打包界面里那个“支持离线”的复选框。
