不能用 ZRANGE + offset 做滚动分页，因其按当前排名序号查询，数据动态变化时会导致漏数、重复或跳榜；应使用 ZRANGEBYSCORE + 游标，以“上一页最后 score 和 member”为断点精确续查。
为什么不能用 ZRANGE + offset 做滚动分页
直接用 ZRANGE key 0 9 WITHSCORES 这类带索引偏移的命令，在数据动态变化时会漏数、重复或跳榜。比如第2页刚取完，有人新上榜，后续页的起始位置就偏了——ZRANGE 是按「当前排名序号」查，不是按「分数+成员」锚定位置。
用 ZRANGEBYSCORE + 游标实现真正滚动分页
核心思路是：不记“第几页”，而记“上一页最后一条的分数和成员”，下一页从这个精确位置往后继续扫。适用于实时榜单（如直播热度、游戏积分）。
- 首次请求用
ZRANGEBYSCORE key -inf +inf WITHSCORES LIMIT 0 10拿前10条 - 拿到最后一条的
score和member，比如["user_102", "842.5"] - 下一页请求：用
ZRANGEBYSCORE key (842.5 user_102 +inf WITHSCORES LIMIT 0 10—— 注意(842.5表示“严格大于”，user_102是同分时的字典序断点 - 如果分数可能重复，必须带上 member 做二级排序，否则同分用户多时会乱序或漏读
ZSCAN 不适合榜单滚动分页
ZSCAN 是遍历内部编码结构（ziplist/skiplist）的游标，不保证按 score 排序返回，也不支持范围过滤。它适合“导出全量”或“后台扫描”，但不能用于用户可见的、按分数排序的榜单分页。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 即使 zset 当前是 skiplist 编码，
ZSCAN返回顺序也不稳定 - 无法跳过指定 score 之前的项，
MATCH只能匹配 member 字符串，不能按分数筛选 - 官方文档明确说：
ZSCAN“not intended for pagination of sorted data”
注意 score 类型和边界符号的写法
Redis 的 ZRANGEBYSCORE 对浮点精度、负无穷、开闭区间很敏感，错一个符号就查不到数据。
- 开区间用
(，如(100表示 >100；[100表示 ≥100（默认就是闭区间） - 负无穷写
-inf，正无穷写+inf，不能写成-INF或inf - 如果 score 是时间戳（整数），避免用浮点格式传参，否则可能因精度丢失导致断点错位
- 当最后一条是最高分时，下一页应返回空——此时游标已到末尾，不要强行拼
+inf继续扫
滚动分页真正的难点不在命令调用，而在客户端正确维护断点：必须把上一页末尾的 score 和 member 一起传回服务端，且处理同分场景下的字典序一致性。少传一个字段，分页就不可靠。
