IndexedDB 错误必须通过 IDBRequest 实例的 onerror 事件捕获，因错误不冒泡且操作全异步；db.onerror 不存在，transaction.onerror 仅在事务中止时触发且无法获取具体错误细节，try-catch 对原生 API 完全无效。
在 IndexedDB 中，try-catch 无法捕获事务操作的运行时错误，因为它只作用于同步代码；而所有 IndexedDB 操作（包括事务内请求）都是异步的。真正有效的错误捕获必须基于事件监听机制，核心是 onerror——但需明确它绑定的对象层级，否则会失效。
事务内请求的 onerror 是唯一可靠入口
每个数据库操作（如 store.get()、store.put()）都返回一个 IDBRequest 实例。错误只在该实例上触发 onerror，不会冒泡到事务或数据库对象上。
- ✅ 正确写法：为每个 request 显式设置
request.onerror = handler - ❌ 错误写法：
db.onerror不存在（浏览器会报TypeError）；transaction.onerror虽存在，但仅在事务因内部请求失败而中止时触发，且此时请求已销毁，无法获取具体错误细节 - ⚠️ 注意：在
onerror回调中调用event.preventDefault()可阻止事务自动中止，适用于想手动处理冲突（如重试或降级）的场景
事务级 onerror 的用途与局限
transaction.onerror 确实存在，但它不是“捕获所有子请求错误”的兜底方案，而是事务生命周期的信号：当任一子请求失败导致事务被系统中止时，它才触发。
- 它的主要价值是统一清理或上报，比如关闭关联的 UI 加载状态、记录日志
- 要定位具体哪个请求出错，仍需通过
event.target拿到那个失败的IDBRequest，再读取其error属性 - 不能在
transaction.onerror中调用transaction.abort()或db.close()，因为事务此时已处于终止状态
为什么 try-catch 完全无效？
IndexedDB 的所有 API 都立即返回 request 对象，实际执行发生在后续微任务中。try-catch 的作用域在同步代码块结束时就已退出，根本覆盖不到异步执行阶段。
- ❌ 错误示例：
try { transaction.objectStore('x').put(data); } catch(e) { ... }—— 这段代码永远不会进入 catch - ✅ 替代方案：把错误处理逻辑封装进 request 的
onerror，或用现代 Promise 封装（如 idb 库），再配合 async/await + try-catch（此时 catch 捕获的是 Promise reject） - ? 提示：若用原生 API 写 Promise 包装器，务必在 request.onsuccess 和 request.onerror 中分别 resolve/reject，且 reject 值应为
request.error
常见静默失败的根源
很多“数据没写入”或“日志缺失”问题，并非没报错，而是错误被忽略或处理不当。
- 未监听 request.onerror → 错误被丢弃，事务自动中止，但 JS 无感知
- 在事务外发起异步操作（如 fetch 后再 put），导致事务提前关闭 → 后续操作抛
InvalidStateError，但若没监听，就变成静默失败 - 多个并发事务写同一 objectStore → readwrite 事务会排队，超时或阻塞可能引发
AbortError，需监听transaction.onblocked做主动响应
