indexeddb是浏览器中唯一能可靠支撑复杂离线应用的原生结构化数据库，具备异步、事务、索引、大容量等核心能力，专为离线场景设计。
支持，而且是专为离线场景设计的结构化存储方案。它不是“能用”，而是当前浏览器中唯一能可靠支撑复杂离线应用的原生数据库。
IndexedDB 为什么是离线存储的核心组件
离线 ≠ 简单缓存页面资源。真实需求包括：保存草稿、同步待办事项、离线浏览历史记录、缓存用户生成内容（如图片 blob）。这些数据有结构、要查询、需事务保障——localStorage 容量小（通常 ≤5MB）、无索引、阻塞主线程；Cache API 只管 HTTP 请求/响应，不能存业务对象。只有 IndexedDB 同时满足：
• 异步非阻塞
• 支持事务（ACID）
• 可建索引、支持范围查询与游标遍历
• 存储上限远高于 Web Storage（通常达数百 MB，取决于浏览器和磁盘空间）
打开数据库时 version 不匹配就失败？onupgradeneeded 是必须项
IndexedDB 的版本控制是硬性机制，不是可选逻辑。每次调用 indexedDB.open('myDB', 3)，若当前数据库版本低于 3，浏览器会触发 onupgradeneeded；若高于 3，则直接报错拒绝打开。常见错误：
• 忘记监听 onupgradeneeded，导致新版本无法创建 objectStore，后续所有操作都抛 InvalidStateError
• 在 onupgradeneeded 中重复调用 createObjectStore（已存在会报错），应先用 db.objectStoreNames.contains('users') 判断
• 升级逻辑里混用读写事务（如在 upgrade 回调中调 transaction('users', 'readwrite')），这是非法的——upgrade 过程本身已是隐式事务，只能直接操作 objectStore
增删改查必须走 transaction，且作用域不能跨表
所有数据操作都必须包裹在 transaction 内，哪怕只是读取一条记录。关键约束：
• transaction 初始化时必须显式声明涉及的 objectStore 名称，例如 db.transaction(['users', 'posts'], 'readonly')
• 不能在同一个 transaction 中对未声明的 store 执行操作，否则报 NotFoundError
• 事务生命周期极短：一旦所有 request 完成（或异常），事务自动关闭；不要试图复用 transaction 实例
• 写操作务必监听 transaction.oncomplete 或 transaction.onabort，而不是仅靠单个 request 的 success/error —— 前者才是事务真正落地的信号
离线时写入成功但网络恢复后没同步？那不是 IndexedDB 的问题
IndexedDB 本身只负责本地持久化，不带同步能力。所谓“离线写入、上线同步”，需要你额外实现：
• 在写入时打标记（如加 syncStatus: 'pending' 字段）
• 监听 navigator.onLine 或 fetch 失败重试机制
• 设计幂等接口，避免重复提交
• 考虑冲突策略（最后写入胜出 / 手动合并）
别指望 IndexedDB 自动帮你连服务器。它和 Cache API 是协作关系：Cache API 缓静态资源和 API 响应，IndexedDB 存业务数据，二者共用一个 Service Worker 生命周期，但数据流向完全独立。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
