lrange 能用于滚动分页但不适用于传统 offset/limit 分页，因其时间复杂度为 o(n)，offset 越大性能越差；适合列表长度几千以内、用户仅浏览前几页的场景，且需注意索引动态变化导致的页不一致问题。
LRANGE 能不能直接当分页用？
能，但只适合“滚动分页”或“小数据量静态列表”，比如消息流、排行榜前100名。它不是为传统 offset/limit 分页设计的——LRANGE 没有跳过前 N 项的底层优化，每次都是从头遍历索引，offset 越大越慢。
常见错误现象：LRANGE mylist 10000 10019 响应明显变卡，Redis 日志里出现 slowlog 记录；并发稍高时 CPU 突增。
- 使用场景：列表长度稳定在几千以内，且用户基本只看前几页（如系统通知、操作日志）
- 参数差异：
start和stop是包含边界（inclusive），LRANGE mylist 0 9取前 10 条，不是 0–9 的偏移 - 注意负数索引：
LRANGE mylist -10 -1是取最后 10 条，这在“最新 N 条”场景很实用
为什么不用 LINDEX 配合循环做分页？
因为更慢、更危险。LINDEX 单次查一个位置是 O(N)，要取 20 条就得调 20 次，网络往返 + 服务端重复遍历，性能雪崩。
典型翻车现场：写个 for 循环跑 LINDEX mylist i 拼出一页，第 5000 页开始每页耗时超 200ms，监控里 cmdstat_lindex 的延迟直线上升。
- 别把 List 当数据库表用：List 是链表结构，没有随机访问能力，Redis 内部得从头一个个 next 指针跳过去
- 如果真要按“页码”查，必须自己维护索引（比如用 Sorted Set 存时间戳+ID），而不是硬扛
LINDEX - 兼容性无问题，但所有 Redis 版本下都慢——这是数据结构决定的，不是版本缺陷
真正适合分页的替代方案有哪些？
取决于你的分页需求类型。如果是“加载更多”（滚动到底部加载下一批），LRANGE 加游标（记录上一页末尾 ID 或 score）完全够用；如果是“跳转任意页码”，List 本身就不该承担这个角色。
- 用
ZSET+ZRANGEBYSCORE：适合按时间、分数排序的分页，比如“2024-04-01 到 2024-04-10 的订单”，score存时间戳，天然支持范围查询 - 用唯一递增 ID +
SCAN配合业务过滤：适用于需要按主键分页且数据已落库的场景，Redis 只缓存热 key，分页逻辑交给 MySQL 或 PostgreSQL - 加一层轻量游标：比如存
last_id到 Hash 里，每次LRANGE后更新，避免反复算 offset，但前提是客户端能接受“不支持跳页”
LRANGE 分页最容易被忽略的边界问题
很多人以为 LRANGE key 0 9 就是第 1 页，10 19 是第 2 页……但一旦中间有 LREM 或 LPOP，索引就全乱了。List 长度动态变化时，“第 N 页”这个概念本身在 Redis 里没有原子保障。
-
stop超出实际长度不会报错，而是返回到末尾为止，容易造成“页大小不一致”（比如期望 20 条，结果只返回 3 条） - 并发写入时，
LRANGE读到的可能是“正在被LPUSH中断”的中间状态，尤其在 pipeline 场景下 - 如果用
BLPOP/BRPOP消费 List，再用LRANGE查剩余内容，要注意阻塞命令会改变 list 长度，LEN和LRANGE之间可能有竞态
分页不是拼函数，是拼对数据一致性和访问模式的理解。List 的 LRANGE 看似简单，但 offset 越大、并发越高、写越频繁，越容易暴露它作为链表的本质限制。
