IndexedDB 的异步 API 本质是模拟磁盘 I/O 真实时序,事务是生命周期固定的执行容器,请求对象单次有效,游标是遍历唯一方式,版本升级仅通过 onupgradeneeded 触发。

IndexedDB 的异步 API 不是为了“避免阻塞”,而是为了匹配底层存储机制的真实行为——磁盘 I/O 无法真正同步完成,强行同步只会冻结主线程。它的设计核心是:**用事件驱动模拟真实时序,用事务边界保障数据一致性,用对象存储替代表格建模**。
事务即执行上下文,不是“开始-提交”两步操作
IndexedDB 中的 transaction 不是传统数据库里可手动 commit/rollback 的逻辑单元,而是一个**生命周期固定的执行容器**。一旦创建,它会自动在所有相关请求(如 get、put、delete)完成后关闭;任何在事务关闭后发起的请求都会直接失败,报 "TransactionInactiveError"。
- 事务必须在打开数据库成功(onupgradeneeded 或 onsuccess 后)立即创建,不能延迟到事件回调外再建
- 所有读写操作必须绑定到该事务对象,例如 store.get(key).onsuccess = ...,而不是先 get 再 attach 事件
- 写操作(add、put、delete)默认使用 readwrite 模式,但需显式声明:db.transaction(['books'], 'readwrite')
请求对象是单次凭证,不可复用也不可缓存
每个 open、get、put 等调用返回的 IDBRequest 实例,只对应一次底层操作。它内部封装了目标存储、参数、事务引用和状态机。一旦 success 或 error 触发,该请求对象就进入“已完成”状态,再次监听 onsuccess 将无效果。
- 不要把 request 对象保存起来后续重复使用;每次操作都应获得新 request
- 错误处理必须绑定在 request 上(request.onerror),而非事务或数据库对象上
- 批量操作需逐个发起请求,或用 cursor 遍历,不能靠“数组+循环+同一个 request”实现
游标(cursor)是遍历的核心,不是语法糖
IndexedDB 没有 SQL 式的 SELECT * FROM table LIMIT 10 OFFSET 20。所有范围查询、分页、条件遍历都依赖 IDBCursor。它本质是一个指向当前记录的指针,配合 continue() 推进,支持 keyRange 过滤与方向控制。
- 用 store.openCursor(range, 'next') 获取游标,range 可为 IDBKeyRange.bound(...) 或 null
- 在 cursor.onsuccess 中检查 event.target.result 是否为 undefined 判断是否结束
- 需要跳过前 N 条时,不建议用 continue() 循环 N 次,而应在游标打开时用 IDBKeyRange.lowerBound(startKey) 定位起始点
版本升级必须通过 onupgradeneeded,且仅在打开时触发
IndexedDB 的 schema 变更(增删 objectStore、index)只能在 onupgradeneeded 回调中进行,且该回调仅在 version number 升高时由 open() 调用触发。它不是“每次打开都执行”,也不是“后台自动迁移”。
- 首次打开数据库或显式调用 open(dbName, newVersion) 且 newVersion > 当前版本时,才会进入 onupgradeneeded
- 在该回调中,可通过 event.target.result.createObjectStore('logs', { keyPath: 'id' }) 创建新 store
- 已有数据不会被自动迁移,需开发者手动读出旧结构数据、转换格式、写入新 store
它不复杂,但容易忽略事务生命周期和请求一次性特征。用好游标和版本控制,就能避开 80% 的典型陷阱。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!










