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% 的典型陷阱。
