indexeddb 分页应避免 cursor.advance() 大偏移，而用 idbkeyrange 结合索引键值定位起点；如按时间分页，可用 lowerbound(1715623400001, true)，复合排序则用数组形式 lowerbound(['active', 1715623400001], true)，且必须确保字段已建索引。
IndexedDB 本身不支持 SQL 那样的 OFFSET 或 LIMIT，也没有内置“跳过前 N 条”的游标操作。但通过 IDBKeyRange、游标方向控制和手动迭代，可以高效实现分页与跳过逻辑——关键不是“跳过”，而是“从某位置开始遍历”。
用游标方向 + 键范围实现分页起点定位
分页的核心是避免从头遍历。比如第 3 页（每页 10 条），不应调用 cursor.advance(20)（性能差且不可靠），而应结合索引键值直接定位起始点。
- 若按时间排序，已知第 2 页最后一条记录的
timestamp = 1715623400000，则第 3 页查询可用：IDBKeyRange.lowerBound(1715623400001, true)（true表示开区间，跳过同值） - 复合排序（如
[status, createdAt]）时，用数组范围：IDBKeyRange.lowerBound(['active', 1715623400001], true) - 务必确保查询字段有对应索引，否则无法利用键范围加速
用 advance(n) 要谨慎，仅适用于小偏移
cursor.advance(n) 会跳过前 n 条匹配项，但它仍需逐条遍历内部节点，对大偏移（如跳过 10000 条）非常慢，且无法中断或取消。
- 适合场景：当前页内微调（如跳过重复项）、总数据量很小（
- 错误用法：
cursor.advance(5000)后再continue()取 10 条 —— 实际执行了 5010 次游标移动 - 替代方案：先用
get()或getAll()查出锚点键，再用lowerBound定位
带状态的游标分页（游标续传）
服务端常用游标 token（如 lastId），IndexedDB 中可模拟：保存上一页最后一条记录的主键或索引键，在下一页查询中作为起点。
- 示例：获取第 2 页后，存下
lastKey = ['published', '2024-05-15T10:23:45'] - 第 3 页查询：
store.index('byStatusTime').openCursor(IDBKeyRange.lowerBound(lastKey, true)) - 注意：必须保证该键在索引中唯一或按预期排序，否则可能漏数据或重复
- 客户端可缓存这个
lastKey，无需服务端参与
避免常见陷阱
分页逻辑看似简单，但 IndexedDB 的异步+事务模型容易引发问题：
- 事务生命周期：游标必须在事务活跃期内使用，不能跨事件循环保存游标对象；每次分页请求需新开事务
- 数据变更影响：分页过程中如有新增/删除，可能导致跳过或重复（非快照读）。如需强一致性，可加锁或用版本号校验
-
空结果处理：
lowerBound可能匹配不到任何记录，需检查cursor是否为null，而非依赖onsuccess -
方向匹配：用
lowerBound时，游标方向必须是"next"；用upperBound分页尾部时，方向应为"prev"
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
