LRANGE可实现分页但仅适用于数据静态、页码靠前场景；因其链表结构导致大offset性能差，索引易因增删偏移，且混用LPUSH/RPUSH会破坏顺序一致性。
Redis List 能做分页，但只适合「数据不变、顺序固定、页码靠前」的场景；lrange 看似简单，一用就踩内存、一致性、边界坑。
为什么 lrange 分页在 Redis List 里容易出错
很多人直接套用 MySQL 的 limit offset 思维：算出 start = (page - 1) * size，再调 lrange key start end。问题在于：
-
lrange的索引是 0-based 且闭区间，end必须 ≥start，否则返回空列表 —— 但很多代码没校验end是否超出llen - List 是链表结构，
lrange底层需遍历到start位置才开始取，当page很大（比如第 1000 页）时，性能断崖式下降 - 只要中间插入/删除一条数据，后续所有页的
start/end全部偏移 —— 没有自动重排机制，和数据库的ORDER BY + LIMIT语义完全不同
lpush/rpush 插入顺序决定分页结果，别混用
Redis List 的顺序完全取决于你用什么命令、在哪一端插入。一旦混用，分页就不可预测：
- 用
rpush从尾部追加，lrange key 0 N取的是最早插入的 N 条（FIFO） - 用
lpush从头部插入，lrange key 0 N取的是最新插入的 N 条（LIFO） - 如果一边
rpush一边lpush，顺序彻底乱掉，lrange返回结果无法按时间或业务逻辑对齐
实操建议：统一用 rpush（保证「先写入先在前」），或统一用 lpush（保证「最新在前」），并在代码注释里写死插入策略。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
分页参数怎么算才不越界
别硬套公式。必须结合 llen 动态截断：
- 先执行
llen key获取当前总长度 - 计算
start = Math.max(0, (page - 1) * size) - 计算
end = Math.min(start + size - 1, llen - 1)（注意：llen - 1是最大合法索引） - 仅当
start 时才执行 <code>lrange key start end，否则返回空列表
示例（Java + Jedis）：
long len = jedis.llen("mylist");
int start = Math.max(0, (page - 1) * pageSize);
int end = Math.min(start + pageSize - 1, (int)len - 1);
List<String> result = start <= end ? jedis.lrange("mylist", start, end) : Collections.emptyList();什么时候该换 zset，而不是硬撑 list
只要出现以下任一情况，立刻放弃 list 改用 zset：
- 需要按时间、分数、权重排序（
list无内置排序） - 页码经常跳转到后半段（
zset的zrange不依赖偏移，查第 1000 页和第 1 页耗时几乎一样） - 数据会动态增删，但要求分页结果稳定（
zset用 score 定位，不受插入位置影响） - 要支持范围筛选（比如「score 在 100~200 之间的前 10 条」），
list根本做不到
真正难的不是写对 lrange，而是判断它是否该被用 —— 大多数线上分页需求，其实早该用 zset 或 ID 列表 + 批量查详情的组合方案了。
