HTML5 IndexedDB 异步API的设计原理与实战应用
谈及IndexedDB的异步API，多数开发者首先想到的是“防止阻塞主线程”。这个理解是正确的，但还不够全面。其更深层的设计哲学在于：真实模拟底层存储设备的异步操作特性。磁盘I/O本身就不是瞬时完成的，若强行设计为同步API，必然导致用户界面卡顿。因此，IndexedDB异步设计的核心精髓可归纳为三点：采用事件驱动模型来契合真实I/O时序，通过严格的事务边界保障数据一致性，并利用灵活的对象存储（Object Store）模型彻底超越传统关系型数据库的表格思维。
事务是执行上下文，而非简单的“开始-提交”
如果你熟悉MySQL等关系型数据库的“BEGIN TRANSACTION”和“COMMIT”模式，那么需要重新理解IndexedDB的事务（Transaction）。在这里，事务更像一个生命周期被严格限定的执行容器。一旦创建，它便自动激活，并持续处理所有关联的数据请求（如get、put），待队列清空后自动关闭。最关键的是，事务一旦关闭，任何后续操作尝试都会立即抛出“TransactionInactiveError”错误——没有任何回旋余地。
- 创建事务的时机必须精准：务必在数据库成功打开（通过
onupgradeneeded或onsuccess事件）后立即进行，切勿在事件回调函数外部创建。 - 所有数据操作都必须绑定到特定的事务对象。正确做法是store.get(key).onsuccess = ...，而非先执行get操作，再附加事件监听器。
- 任何写入操作（add、put、delete）都必须显式声明读写模式：db.transaction(['books'], 'readwrite')，仅靠默认模式无法完成写入。
请求对象是单次操作凭证，不可复用与缓存
每次调用open、get、put等方法时，返回的IDBRequest对象本质上是一张“一次性票据”。它封装了本次操作的全部元数据：目标存储空间、操作参数、关联事务及当前状态。一旦其success或error事件被触发，该票据即告失效，再次监听其onsuccess将毫无响应。
- 切勿缓存或复用request对象；每次数据操作，都应获取全新的request实例。
- 错误处理必须绑定到具体的request对象（即request.onerror），而非笼统地挂载到事务或数据库对象，否则无法捕获精确的错误信息。
- 处理批量操作时，应逐个发起独立请求，或使用游标（cursor）进行遍历。避免尝试“通过循环复用同一个request对象”的捷径，这会导致不可预知的行为。
游标（Cursor）是遍历核心机制，而非语法糖
若希望在IndexedDB中执行类似“SELECT * FROM table LIMIT 10 OFFSET 20”的查询，需要转换思路。所有高级数据操作，如范围查询、分页加载、条件遍历，都必须依赖IDBCursor游标实现。游标本质上是一个指向当前数据记录的指针，通过continue()方法逐步推进，并配合IDBKeyRange对象实现灵活的键值范围过滤与遍历方向控制。
掌握游标机制对于前端高级数据管理至关重要，建议开发者系统学习以填补知识盲区。
- 使用store.openCursor(range, 'next')开启游标。其中
range参数可通过IDBKeyRange.bound(...)指定范围，若无限制则传入null。 - 在
cursor.onsuccess回调中，判断遍历是否结束的关键是检查event.target.result是否为undefined。 - 若需跳过前N条记录，更高效的做法是使用
IDBKeyRange.lowerBound(startKey)直接定位起始键，而非在循环中调用N次continue()。
版本升级必须通过onupgradeneeded，且仅在打开时触发
需要对数据库结构进行“手术”，例如新增或删除对象存储（ObjectStore）与索引（Index）？唯一的入口是onupgradeneeded回调。此入口设有严格条件：仅在打开数据库时提供的版本号高于当前持久化版本时，才会触发一次。它不会在每次打开时运行，也不会自动执行数据迁移。
- 触发条件有两种：首次创建数据库，或显式调用
open(dbName, newVersion)且newVersion大于现有版本号。 - 在此回调中，可执行类似event.target.result.createObjectStore('logs', { keyPath: 'id' })的代码来创建新的存储结构。
- 需特别注意：已有数据不会自动迁移。若数据结构变更，开发者必须手动编写代码，读取旧结构数据、进行格式转换、再写入新存储中。
客观而言，IndexedDB的API设计并不复杂，但大多数常见问题都源于忽视了其“事务生命周期固定”与“请求对象一次性”两大核心特性。只要深入理解游标的使用方法与版本升级机制，便能有效规避80%以上的典型开发陷阱。
