如何利用 IndexedDB 游标高效扫描海量本地离线日志数据
使用 IndexedDB 游标处理海量离线日志时，真正的技术难点并非简单的数据遍历，而在于如何确保整个扫描过程流畅、稳定且数据完整。十万条日志记录看似不多，但每条若包含时间戳、用户标识、操作类型及复杂的JSON负载，其总体内存占用轻松超过200MB。游标机制虽能避免一次性加载全部数据，但若应用不当，极易引发界面卡顿、内存泄漏和频繁的垃圾回收，导致应用崩溃。
游标启动策略：精准定位起点，善用范围与方向
直接调用 store.openCursor() 进行全表扫描，在处理日志数据时风险极高。实际业务场景通常有明确目标，例如“检索今日所有错误日志”或“从特定检查点继续同步”。更专业的做法是，优先结合索引与范围查询来精确限定扫描区间：
- 为高频查询字段建立索引：对于 timestamp（时间戳）、level（日志等级）、sessionId（会话标识）等常用筛选字段，务必创建对应的非唯一索引以加速查询。
- 基于时间窗口进行扫描：使用 store.index('timestamp').openCursor(IDBKeyRange.bound(startTime, endTime))，能有效限定数据范围，大幅提升初始查询效率。
- 采用反向遍历获取最新记录：对于需要加载最新日志或实现翻页的场景，使用 openCursor(null, 'prev') 进行反向遍历，比获取全部数据后再进行数组反转要高效得多。
遍历性能优化：掌握 advance() 方法，实现分批处理
若仅简单循环调用 cursor.continue()，面对十万量级的数据，将产生同等数量的微任务，严重阻塞主线程，导致用户界面无响应。更优的策略是采用分批次跳跃式处理：
- 利用 advance() 实现批量跳过：cursor.advance(100) 可一次性跳过指定数量的记录，相比连续执行100次 continue()，能极大减少任务调度与上下文切换的开销。
- 结合时间切片控制执行节奏：每处理完一个批次的数据（建议50-200条），主动让出主线程控制权。可借助 setTimeout、requestIdleCallback 或 queueMicrotask 实现“处理-让步-继续”的循环，保持应用流畅。
- 推荐实践模式：在当前批次处理完成后，不立即调用 advance，而是通过 queueMicrotask(() => cursor?.advance(batchSize)) 来调度下一次推进，确保浏览器事件循环不被阻塞。
内存管理与中断恢复：流式处理与可控退出
日志扫描通常用于数据导出、实时分析或过滤，无需将所有中间结果存储在内存数组中。最佳实践是采用流式处理架构：
- 即用即弃，及时释放内存：每当获取到 cursor.value，立即进行必要的解析、过滤或写入目标（如另一个ObjectStore、Blob文件或网络流），随后主动解除对该条数据的引用，以利于垃圾回收器及时回收内存。
- 设计可中断的扫描流程：在遍历循环中嵌入 if (abortSignal.aborted) return 判断，并结合 AbortController 或用户界面按钮事件，允许用户随时安全地终止长时间运行的扫描任务。
- 避免在回调中阻塞页面渲染：切忌在游标的 onsuccess 回调内执行密集的DOM更新操作（如频繁设置 innerHTML）。应改用 DocumentFragment 进行批量DOM组装，或对渲染逻辑进行防抖与节流优化。
错误处理与健壮性保障：主动捕获，避免静默失败
一个常见的陷阱是：游标请求失败时默认不会抛出异常，也不会自动重试，它会无声无息地停止工作——这种静默失败行为是系统不稳定的主要根源。构建健壮的扫描逻辑必须主动处理各类异常：
- 为所有游标请求绑定错误监听：每个由 openCursor() 返回的请求对象，都必须设置 onerror 事件处理程序，例如：request.onerror = e => console.error('游标打开失败', e.target.error)，并进行相应的重试或降级处理。
- 准确判断游标遍历终点：游标可能因事务自动提交或数据库连接关闭而提前失效。因此，不能仅依赖 onsuccess 回调，必须检查 cursor === null 来作为遍历完成的唯一可靠标志。
- 选择匹配的事务模式：对于纯读取的扫描操作，使用 'readonly' 事务模式即可；若需在遍历过程中同步删除或修改记录，则必须启用 'readwrite' 事务，并注意写入操作对当前游标位置可能产生的影响。
