Redis 缓存列表时，分页 key 不要只拼页码

列表页做缓存，最先想到的写法通常很直接：第一页缓存成一个 key，第二页再来一个 key。
刚开始看完全没问题，可 2014 年我在给后台列表和内容列表做 Redis 缓存时，很快就遇到现实难题：真正决定一页内容的，根本不只是页码。

只拼页码为什么会出错

因为一个列表结果往往同时受到很多条件影响：

• 排序方式
• 分类或状态筛选
• 搜索关键词
• 当前版本或展示策略

如果 key 里只带页码，缓存命中虽然看起来很高，返回的内容却可能早就不是同一组查询条件对应的结果。

我后来更喜欢怎么想列表缓存

我不再把它理解成“第几页”，而是“某个查询视图的第几页”。
也就是说，缓存 key 至少要表达出这个列表视图最关键的维度，而不是只表达页码这个表面索引。

哪些字段应该进 key

不是所有参数都要原样塞进去，但我通常会保留：

• 列表类型
• 主要筛选条件
• 排序方式
• 页码

如果还涉及接口版本或渲染版本，我也会一起带进去，避免旧缓存混进新结构。

小结

Redis 做分页缓存时，真正要缓存的不是“1、2、3 页”这种数字，而是“某个具体查询视图的分页结果”。
2014 年之后我对列表缓存越来越保守，就是因为看过太多“命中了缓存，但内容不对”的情况。只拼页码看似省事，实际会把问题往后推得更远。