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，光靠打包工具勾选“离线模式”毫无意义。

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

• Service Worker 是目前唯一可靠的离线方案，需注册 + 安装 + 拦截 fetch 事件，缓存 HTML/JS/CSS/图片等静态资源
• 缓存策略要区分：首屏资源（cache-first）、API 数据（network-first fallback 到 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() 成功 —— 而不是打包界面里那个“支持离线”的复选框。