indexeddb大批量写入易因事务超时、阻塞等导致失败，优化需分块写入（每批100–500条）、promise封装事务、web worker解耦、分级错误重试与降级。
HTML5 本身不直接支持数据库事务，所谓“事务挂起”问题实际发生在使用 IndexedDB（HTML5 标准的客户端数据库）进行大批量数据写入时。由于 IndexedDB 的事务具有生命周期限制（如超时自动中止、事件循环阻塞、资源竞争等），在高频率或大数据量写入场景下容易出现事务提前终止、请求排队失败、DOM 阻塞甚至浏览器无响应等问题。优化核心在于：**避免长事务、分片控制、异步解耦、错误兜底**。
分块写入 + 事务复用
单个事务内写入过多记录（如上万条）极易触发浏览器内部事务超时（Chrome 默认约 60 秒，且不可配置）或内存压力导致中止。应主动将数据切分为小批次（建议每批 100–500 条），每批使用独立事务，并在事务成功后立即启动下一批：
- 不要在单个 transaction 中循环 put() 上万次
- 使用递归或 Promise 链控制批次节奏，例如：await writeBatch(data.slice(0, 200)); then writeBatch(data.slice(200))
- 每批事务保持短生命周期（毫秒级），降低被系统回收风险
使用 async/await + IDBRequest Promisify 封装
原生 IndexedDB 基于事件回调（onsuccess/onerror），嵌套深、错误流难追踪，易造成“事务已关闭却继续操作”的挂起假象。统一封装为 Promise 可提升可控性：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 对 open()、add()、put()、clear() 等操作返回 Promise，拒绝时明确 reject 事务错误
- 在 await 每个写入批次后检查事务状态（transaction.db || transaction.objectStoreNames.length），避免后续操作作用于已失效事务
- 捕获 AbortError、TransactionInactiveError 等典型异常并触发重试或降级逻辑
启用多进程写入（Web Worker + IndexedDB）
主线程执行大量 IndexedDB 写入会阻塞渲染和交互，用户感知为“页面卡死”，实质是事件循环被阻塞而非事务真正挂起。将写入逻辑移至 Web Worker 可彻底解耦：
- Worker 内打开独立 IndexedDB 连接，事务完全隔离，不影响 UI 响应
- 主线程通过 postMessage 分批发送数据块，Worker 接收后执行分块写入并反馈进度
- 注意：部分旧版 Safari 对 Worker 中 IndexedDB 支持有限，需降级检测
设置合理的错误重试与回退机制
网络不稳定、存储空间不足、并发冲突都可能导致事务失败。单纯重试可能加剧问题，需分级策略：
- 瞬时错误（QuotaExceededError）：暂停 100ms 后重试，最多 3 次；失败则触发清理或提示用户释放空间
- 事务冲突（AbortError / TransactionInactiveError）：立即新建事务重试当前批次，不沿用旧事务引用
- 连续失败超阈值（如 5 批全失败）：暂停写入，记录日志，切换为本地缓存（localStorage 或 JS Array）暂存待同步数据
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
