IndexedDB原生支持离线存储，数据本地持久化、结构化、事务安全；离线读不到数据多因未处理upgradeneeded、Service Worker依赖失败或db实例引用错误；容量受浏览器策略限制，但不会被自动清理。
IndexedDB 本身不是“兼容离线存储”，而是**原生支持离线存储**——它不依赖网络，数据存在本地，关机重启后仍在，只要用户没手动清除站点数据。
IndexedDB 真正的离线行为：数据完全本地化
IndexedDB 数据写入的是浏览器分配的私有存储空间（路径类似 chrome://settings/siteData 或 about:storage），和网络连通性完全解耦。哪怕拔掉网线、飞行模式、甚至断电再开机，只要没清空该站点数据，indexedDB.open() 仍能正常打开数据库并读写。
- 它不像
localStorage那样只能存字符串，而是支持ArrayBuffer、Blob、Date、嵌套对象等结构化数据 - 事务机制保证多操作原子性，比如“下载文件 + 更新元数据”必须一起成功或一起失败，避免离线时数据不一致
- 没有网络时调用
db.transaction().objectStore().add()不会报错，也不会静默丢弃——只要数据库已打开，写操作照常排队执行
为什么有时“离线后读不到数据”？常见误判点
这不是 IndexedDB 本身失效，而是开发中容易混淆的几个环节：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
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 的“离线可靠”建立在“你正确处理了版本升级、事务错误、连接生命周期”之上；它不帮你做网络重试、冲突合并或跨设备同步——这些得靠你在上层封装逻辑补全。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
