Redis List 不能直接用 LRANGE 做“第 N 页”查询，因其依赖固定索引，数据增删会导致偏移错乱，且不支持条件过滤；应改用 Sorted Set 定位 ID + Hash 存储数据的双结构方案。
Redis List 存储分页数据时，为什么不能直接用 LRANGE 做“第 N 页”查询
很多人一看到“用 Redis 做分页”，就直接往 List 里 LPUSH 所有数据，再用 LRANGE myList 20 39 取第二页 —— 这在小数据量下看似可行，但实际踩了两个坑：
一是 List 的 LRANGE 虽快，但要求你**提前知道每条记录的全局位置索引**（比如第 21 条在 List 中就是 index=20），而这个索引必须和数据库主键/时间戳严格对齐；二是如果数据有增删，List 索引会整体偏移，导致翻页错乱或漏数据。
更关键的是：Redis List 本身不支持条件过滤，你无法像 SQL 那样写 WHERE status = 1，所有筛选逻辑得在写入前完成。
真正能落地的方案：用 Redis Sorted Set + List 双结构协同
Sorted Set 解决定位问题，List 解决内容存储问题，二者靠 ID 关联。这不是炫技，而是为了绕过 MySQL 大 offset 的硬伤。
具体做法是：
- 写入时：用
ZADD index_set 100500 "100500"把主键作为 score 存进有序集合（score 必须是能排序的字段，如自增 ID 或 UNIX 时间戳） - 同时把完整记录序列化后存进 List：
LPUSH data_list '{"id":100500,"name":"xxx"}' - 查第 2 页（每页 20 条）时，先用
ZRANGEBYSCORE index_set 100501 +inf WITHSCORES LIMIT 0 20拿到 20 个 ID 和 score，再用这些 ID 去 List 中批量取值（需提前约定 ID → List index 映射，或改用 Hash 存 ID→data）
注意：ZRANGEBYSCORE 返回的是按 score 排序的 ID 列表，不是 List 下标。如果你没做 ID 到 List index 的映射，就别强行用 List 存原始数据 —— 改用 HSET data_hash 100500 '{"id":100500,"name":"xxx"}' 更稳妥。
ThinkPHP 里怎么安全地集成这套逻辑
不要在控制器里拼 Redis 命令，容易出错且难复用。应该封装成模型方法，并强制走缓存一致性流程：
立即学习“PHP免费学习笔记（深入）”；
- 每次写入新记录，必须同步执行：
ZADD+HSET+ （可选）更新总记录数缓存INCR page_total_count - 读取分页时，优先从
ZRANGEBYSCORE拿 ID 列表，再用HMGET data_hash id1 id2 ...批量取数据，避免 N+1 - 在 ThinkPHP 中调用 Redis，统一走
Cache::store('redis')，但注意：TP8 的store()不支持原生命令，得用think\cache\driver\Redis实例或直接 new \Redis() - 缓存失效策略要明确：比如用户编辑某条记录，除了删
HSETkey，还得从ZSET中ZREM对应 ID，否则分页还会查到旧快照
最常被忽略的一点：Redis 分页不提供“总页数”。前端不能渲染「共 127 页」这种信息，只能给「下一页」「上一页」按钮，或者用 ZCARD index_set 估算总数（但高并发下可能不准）。
比 List + ZSet 更轻量的替代：只用 Redis Hash 存游标分页结果
如果业务场景是固定条件（如“最近 30 天订单”）、低频更新、高并发读，可以直接把整页结果序列化后存进 Hash：HSET page_cache:orders:20260817:1 '["order_1","order_2"]'，key 中嵌入日期和页码作为分片维度。
优点是读取极快（一次 HGET），缺点是写入成本高（全量重算）、不支持动态跳页。
适合这类场景：
- 后台报表类页面，数据每小时刷一次
- 首页推荐流，内容由定时任务预生成
- 搜索结果页，关键词热度低、缓存命中率高
这种方案完全绕开了分页算法复杂度，但代价是牺牲实时性 —— 它不是“查询优化”，而是“结果缓存”。上线前务必确认业务能否接受分钟级延迟。
