indexeddb异常处理必须聚焦请求级监听、事务生命周期控制、版本结构校验和配额预判四环节：错误只绑定idbrequest不冒泡，db.onerror不存在，事务失败需通过event.target.error识别并abort，onblocked/onversionchange须主动响应，配额需前置探测与降级。
IndexedDB 异常处理不能靠“catch 住所有错误”来解决。它本质是事件驱动、请求绑定、事务约束的异步系统，错误只发生在具体请求上，不会自动冒泡，也不会由数据库或事务对象直接抛出。真正有效的处理，必须落在请求监听、事务生命周期控制、版本与结构校验、以及配额预判这四个关键环节。
请求级错误必须显式监听
IDBRequest（包括 IDBOpenRequest）是错误发生的唯一载体。db.onerror 不存在，transaction.onerror 虽可监听但实际是事务内任一请求失败时触发，仍需通过 event.target 拿到出错的具体请求对象。
- 每个 get()、put()、add()、delete() 等操作返回的 request 实例，都必须设置 onerror 和 onsuccess；
- open() 返回的 IDBOpenRequest 同样要监听 onerror，常见错误如 QuotaExceededError（空间不足）、VersionChangeAbortError（版本冲突）；
- 不要在 onsuccess 中提前调用 db.close()，否则后续请求会因 InvalidStateError 失败；应等所有 request 完成后再关闭。
事务失败要区分原因并主动终止
事务中任一请求失败，默认导致整个事务中止（AbortError），但静默失败（如日志未写入）往往源于事务提前结束——比如异步逻辑未纳入事务上下文，或事务对象被垃圾回收。
- 事务开启后，所有 store 操作必须使用该 transaction 对象获取 store，不能重新从 db 获取；
- 避免在事务回调中嵌套 setTimeout、fetch 等脱离事务生命周期的操作；
- 监听 transaction.oncomplete 和 transaction.onerror，出错时可通过 event.target.error 判断类型（如 QuotaExceededError 或 AbortError），并明确调用 transaction.abort() 防止残留状态。
阻塞问题：onblocked 与 onversionchange 是关键信号
当新版本数据库打开时，旧标签页仍在使用旧版本数据库，就会触发阻塞。此时 open 请求不会失败，但会卡住，直到旧连接关闭或超时。
- 务必监听 IDBOpenRequest 的 onblocked 事件，在其中提示用户刷新页面或关闭其他标签页；
- 监听 IDBDatabase 的 onversionchange 事件，收到后应主动调用 db.close()，释放连接；
- 不要依赖自动重试——阻塞可能持续数分钟，需引导用户干预。
存储溢出需主动探测+分级降级
浏览器不提供实时配额 API，QuotaExceededError 往往在 commit 阶段才抛出，此时事务已无法挽救。必须前置预判。
- 对 IndexedDB，可在初始化时尝试写入小批量测试数据，捕获 AbortError / QuotaExceededError；
- 维护写入计数器 + 平均条目大小估算，接近阈值（如 80%）时触发自动清理（按时间戳或优先级删除旧数据）；
- 降级路径要明确：批量写入失败 → 拆为 20–50 条/批重试；全部持久化失败 → 切换至内存 Map 缓存，并标记“离线暂存”，页面卸载前尝试存入 sessionStorage（部分浏览器仍允许）。
