游标分页比getAll()更优，因后者一次性加载全部数据易致内存溢出，而游标按需拉取、支持从指定位置续读；其核心是基于有序主键或时间戳构建IDBKeyRange范围查询，配合cursor.continue()实现高效分页。
cursor游标遍历为什么比直接 getAll() 更适合分页
当数据量超过几千条时，getAll() 会一次性把所有记录加载进内存，容易触发浏览器内存警告甚至卡死页面；而 cursor 是逐条或按块拉取，可控性强，也天然支持「从某位置继续读」——这正是分页的核心需求。
关键点在于：IndexedDB 的游标本身不保存状态，每次打开游标都是新起点，所以必须靠 IDBKeyRange.bound() 或游标 continue() 来控制起始/终止位置。
- 用
openCursor()配合IDBKeyRange.lowerBound(startKey, true)实现「跳过前 N 条」 - 用
cursor.advance(n)可跳过 n 条，但仅适用于主键有序场景，且无法跳转到任意页（比如第 100 页），慎用 - 真正健壮的分页应基于游标 + 键范围（key range），而非依赖偏移量（offset）
如何用 cursor 实现「下一页」式分页（带 lastKey 记录）
最常用、兼容性最好的方式是记录上一页最后一条记录的主键（cursor.key），作为下一页查询的起点。这要求主键可比较（如 number、date 字符串、自增 ID），且索引已排序。
示例逻辑：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const transaction = db.transaction('users', 'readonly');
const store = transaction.objectStore('users');
// 假设上一页最后一条的 key 是 123，要取下一页 20 条
const range = IDBKeyRange.lowerBound(123, true); // true 表示不包含 123
const request = store.openCursor(range);
let count = 0;
const results = [];
request.onsuccess = function(e) {
const cursor = e.target.result;
if (cursor && count < 20) {
results.push(cursor.value);
count++;
cursor.continue(); // 继续下一条
} else {
// 此时 results 就是下一页数据，cursor?.key 是本页最后 key，留作下次用
}
};
- 注意
IDBKeyRange.lowerBound(123, true)中的true——漏掉会导致重复读取第 123 条 -
cursor.continue()不传参时，按主键顺序取下一条；传入 key 时，会跳转到 >= 该 key 的第一条（需确保 key 存在且有序） - 如果用 index 查询（非主键），必须先用
index.openCursor()，且 range 要基于索引字段值，不是主键
cursor 分页遇到复合主键或非数字 key 怎么办
当主键是数组（如 [year, id]）或字符串（如 "2024-05-01_abc123"）时，lowerBound 依然有效，但比较逻辑依赖字典序或结构化规则。
例如主键为 ["2024", "user_001"] 的数组，想跳过前 50 条后读取下 20 条：
- 不能简单用
lowerBound(50)—— 数组和数字不可比 - 必须先通过一次游标遍历，拿到第 50 条的完整主键值（如
["2024", "user_050"]），再用它构造IDBKeyRange.lowerBound(["2024", "user_050"], true) - 字符串 key 如
"2024-05-01T10:30:00Z_user_123"，只要时间戳部分严格 ISO 格式，字典序就等于时间序，可直接用于 range
常见坑：cursor.key 在复合主键下是数组，JSON.stringify 后存储没问题，但恢复时必须解析回数组才能用于 lowerBound，否则类型不匹配导致游标为空。
性能与边界情况必须检查的三件事
游标分页看似简单，但在真实项目中，以下三点不处理就会出错：
- 事务生命周期：游标必须在事务完成前消费完，否则
onsuccess可能收不到后续结果；建议用transaction.oncomplete做兜底清理，而非依赖游标自动关闭 - 数据动态变更：分页过程中，若其他写操作插入了 key 在当前 range 内的新记录，会导致重复或遗漏；业务上需接受「快照语义」，或加锁/版本号机制（IndexedDB 本身不提供行锁）
- 游标越界：当
cursor.continue()后e.target.result为null，说明已到末尾，此时若仍尝试cursor.continue()会报错InvalidStateError: Cursor is being iterated or is done
最后一句提醒：不要试图用游标实现「总页数」或「跳转到第 N 页」——IndexedDB 没有 count(*) 快速接口，真需要，得单独建一个计数缓存字段，定期更新。
