HTML IndexedDB兼容离线存储吗_离线存储对HTML IndexedDB限制对比

IndexedDB原生支持离线存储，数据本地持久化、结构化、事务安全；离线读不到数据多因未处理upgradeneeded、Service Worker依赖失败或db实例引用错误；容量受浏览器策略限制，但不会被自动清理。

IndexedDB 本身不是“兼容离线存储”，而是**原生支持离线存储**——它不依赖网络，数据存在本地，关机重启后仍在，只要用户没手动清除站点数据。

IndexedDB 真正的离线行为：数据完全本地化

IndexedDB 数据写入的是浏览器分配的私有存储空间（路径类似 chrome://settings/siteData 或 about:storage），和网络连通性完全解耦。哪怕拔掉网线、飞行模式、甚至断电再开机，只要没清空该站点数据，indexedDB.open() 仍能正常打开数据库并读写。

• 它不像 localStorage 那样只能存字符串，而是支持 ArrayBuffer、Blob、Date、嵌套对象等结构化数据
• 事务机制保证多操作原子性，比如“下载文件 + 更新元数据”必须一起成功或一起失败，避免离线时数据不一致
• 没有网络时调用 db.transaction().objectStore().add() 不会报错，也不会静默丢弃——只要数据库已打开，写操作照常排队执行

为什么有时“离线后读不到数据”？常见误判点

这不是 IndexedDB 本身失效，而是开发中容易混淆的几个环节：

• indexedDB.open() 在离线时首次调用可能触发 upgradeneeded，但若代码里只监听 success 和 error，漏掉 upgradeneeded，会导致数据库没建好就去读，返回空
• 页面加载时依赖 Service Worker 缓存 HTML/CSS/JS，但 JS 里初始化 IndexedDB 的逻辑被写在 fetch 回调里——离线时 fetch 失败，整个初始化流程卡住，DB 根本没打开
• 使用了 event.target.result 后未保存 db 实例引用，后续操作用闭包外的旧变量，实际调用的是已关闭或未初始化的 IDBDatabase
• 某些安卓 WebView 或旧版 Safari 对 indexedDB.deleteDatabase() 有 bug，离线状态下删库失败但不抛错，导致误以为“数据还在”，其实是新库没建起来

容量与持久化：别把 IndexedDB 当临时缓存盘

IndexedDB 没有固定上限，但受浏览器策略约束：

立即学习“前端免费学习笔记（深入）”；

• Chrome / Edge：默认约占用磁盘空间的 80%，单个 origin 最高可达数 GB（取决于可用磁盘）
• Safari：iOS 上严格限制为 50MB（硬限制），macOS 更宽松但需用户授权“永久存储”
• Firefox：无硬上限，但会根据磁盘剩余空间动态调整，长期不用的数据可能被自动清理（非强制）
• 所有浏览器都可能在存储压力大时触发 storage 事件，但不会主动删 IndexedDB 数据——除非用户手动清除“网站数据”或启用“自动清除浏览数据”策略

真正容易被忽略的是：IndexedDB 的“离线可靠”建立在“你正确处理了版本升级、事务错误、连接生命周期”之上；它不帮你做网络重试、冲突合并或跨设备同步——这些得靠你在上层封装逻辑补全。