indexeddb事务由事件循环以宏任务调度，其回调（onsuccess/oncomplete）在所有微任务后执行；事务生命周期由底层数据库控制，js主线程仅注册回调，不直接管理提交或中止。
IndexedDB 的异步事务由事件循环统一调度，但它的执行逻辑和普通 Promise 微任务不同——事务本身不直接进入微任务队列，而是依赖底层数据库引擎完成 I/O 后，通过内部回调触发 success/error 事件，再由事件循环将这些回调推入任务队列（宏任务）。
事务生命周期不由 JavaScript 主线程控制
IndexedDB 事务（IDBTransaction）一旦创建并发起请求（如 objectStore().get()），其读写操作实际交由浏览器的后台数据库线程（或进程）处理。JavaScript 主线程只负责注册回调（onsuccess、onerror、oncomplete），并不等待结果。事务是否活跃、何时提交或中止，取决于底层存储层的状态，而非 JS 执行流。
- 事务在所有待定请求完成且无未处理错误时自动进入
commit流程；若任一请求失败且未被捕获，事务会立即abort -
transaction.oncomplete和request.onsuccess回调属于“事件驱动”的任务，被放入**任务队列（task queue）**，不是微任务队列 - 这意味着它们总在当前宏任务结束、所有微任务（如 Promise.then）执行完之后才运行
Promise 化 IndexedDB 时要注意任务时机
用 new Promise 封装 IDB 请求很常见，但容易误以为它等同于原生 Promise 行为。实际上，Promise 构造函数中的执行器（executor）是同步运行的，而 IDB 回调是异步触发的：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 构造 Promise 时，你立刻调用
objectStore.get(key)，但request.onsuccess要等数据库返回后才被事件循环拾取 - 因此
await getFromIDB()确实暂停了 async 函数，但暂停点之后的代码，仍要等整个事务相关回调（包括 oncomplete）所对应的任务执行完毕 - 多个连续的 IDB 操作（如先 add 再 get）若共享同一事务，它们的回调可能在同一个任务中批量触发；若跨事务，则各自独立排队
避免事务意外关闭的典型陷阱
事务有自动生存期：只要还有未完成的请求（即 request 对象尚未触发 success/error），事务就保持 active；一旦所有请求 settled，事务进入 "committing" 或 "aborted" 状态，此时再发新请求会报错 “Transaction inactive”。
- 不要在
onsuccess中发起新请求却不显式保留事务引用——虽然通常能工作，但逻辑上已脱离事务上下文 - 避免在事务 active 期间让 JS 执行长时间同步代码（如大循环），否则可能触发浏览器判定为“卡死”，间接影响事务超时机制（尤其在某些旧版本 Edge/IE）
- 不推荐用
setTimeout(..., 0)延迟请求——它会创建新任务，大概率导致事务早已关闭，引发 InvalidStateError
调试建议：用 Performance 面板观察任务分发
在 Chrome DevTools 的 Performance 面板中录制操作，可清晰看到 IndexedDB 相关回调作为独立的 “Event: idb” 出现在主线程任务列表中，其开始时间晚于 preceding Promise microtasks，也晚于定时器或用户交互事件。
- 对比
Promise.resolve().then(...)和request.onsuccess = () => {...}的执行顺序，能直观验证宏任务 vs 微任务差异 - 监听
transaction.onabort和transaction.onerror可捕获静默失败（比如并发写冲突或磁盘满） - 使用
transaction.db.onversionchange处理数据库被其他标签页升级导致的强制中断
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
