游标遍历内存过高源于错误使用，应控制节奏、切断引用、流式处理：边扫边清、分批推进、精准索引、显式释放。
游标遍历本身不加载全部数据，内存过高往往来自错误的使用方式——比如把所有结果攒进数组、没及时释放引用、或在主线程同步做重操作。关键不是“避免用游标”，而是“控制节奏+切断引用+流式处理”。
边扫边清，别攒数组
游标每次回调只暴露一条记录（cursor.value），但很多人习惯先 push 到一个 results 数组里，等遍历完再统一处理。10 万条中等对象，光这个数组就可能占上百 MB。正确做法是：拿到一条，立刻做业务逻辑（比如写入新 store、匹配关键词、生成 Blob 片段），处理完马上丢弃引用。
- 不要写
results.push(cursor.value)；改用processOneRecord(cursor.value)，函数内部不保留长期引用 - 若需汇总统计（如计数、求和），用几个原始变量累加，而非存对象
- 导出场景下，可配合
Blob+WritableStream（如支持）边写边输出，不缓存全文本
分批推进，主动让出主线程
逐条 cursor.continue() 会排队大量微任务，阻塞渲染。应改用 cursor.advance(n) 分组跳过，并配合时间切片调度。
- 每处理 50–200 条后，调用
cursor.advance(100)，比连续 100 次continue()开销更低 - 用
queueMicrotask(() => cursor?.advance(100))或setTimeout(() => ..., 0)把下一批推到下一帧，保持页面响应 - 避免在
onsuccess回调里写while循环或递归无节制调用continue()
精准范围 + 合理索引，减少扫描总量
内存压力常源于“不该扫的也扫了”。游标默认全表遍历，但真实需求通常有明确边界——比如只查某天日志、某个用户行为序列。
立即学习“Java免费学习笔记（深入）”；
- 为高频查询字段建索引（如
timestamp、level、userId），并用IDBKeyRange.bound(start, end)限定范围 - 按索引开游标：
index.openCursor(range)，确保只遍历目标子集 - 反向扫描最新数据（如翻页加载）用
openCursor(null, 'prev')，避免拉全量再 reverse
事务与引用必须显式管理
游标和事务生命周期不自动绑定 GC，未释放的引用会持续占用内存，尤其在长时遍历中极易泄漏。
- 事务完成即监听
oncomplete，手动设cursor = null、transaction = null - 避免闭包意外捕获游标或 value；处理完一条后，显式将局部变量赋值为
null - 给长任务加退出开关，比如配合
AbortController.signal，中途取消时立即终止游标推进
