gorm不支持缓存预热式分页，因分页结果依赖实时数据库快照、排序稳定性及偏移位置，易受新数据插入影响而失效；预热反而放大脏数据风险且无法预测随机页码访问。
GORM 本身不支持缓存预热式分页，所谓“基于缓存预热提升分页性能”是个伪命题——分页结果天然不可缓存，除非你放弃数据实时性、硬编码固定页码数据。
为什么分页结果不能靠缓存预热来加速
分页接口的核心矛盾在于：每页数据都依赖当前数据库快照 + 排序稳定性 + 偏移位置。哪怕只有一条新记录插入到排序靠前的位置，后续所有页的 Offset 结果都会偏移。缓存“第3页的20条用户”在1秒后就可能失效，而预热它反而会放大脏数据风险。
- 预热缓存需要提前知道哪些 page/size 组合会被访问，但真实请求是随机的（比如用户直接跳转到第87页）
- 缓存分页结果必须连带缓存 total 计数，而 COUNT(*) 在高并发写入下极易过期
- GORM 的
Find、Limit、Offset都不生成可复用的缓存 key；即使你用 Redis 存了page=5&size=20&sort=id_asc的结果，也无法保证下次查时语义一致
真正有效的“类预热”替代方案
与其试图缓存分页结果，不如把资源投向能稳定提升首次响应速度的环节：
- 对排序字段（如
id、created_at）建立联合索引，覆盖常用查询条件，避免ORDER BY + WHERE触发 filesort - 用
db.Session(&gorm.Session{PrepareStmt: true})开启预编译，让Limit/Offset查询复用执行计划，实测提升 30%+ QPS - 对高频分页路径（如后台管理“最近7天订单”）单独建物化视图或定时汇总表，把 COUNT 和分页主表分离
- 前端加载时主动请求
page=1&size=1获取 total，再并行拉取首屏数据——避免阻塞式 COUNT 拖慢首屏
如果非要缓存，只能缓存元信息而非结果
可安全缓存的只有不随数据变更的结构化元信息：
- 分页参数合法范围（如最大
page_size=100），存在本地变量或配置中心，无需每次解析 - 字段排序规则映射表（如
"updated"→"updated_at DESC, id DESC"），避免字符串拼接出错 - WHERE 条件白名单（如只允许按
status、category过滤），校验逻辑可提前缓存在中间件
这些都不涉及具体数据，不会因写入而失效，也无需考虑缓存穿透或雪崩。
分页性能瓶颈从来不在“要不要缓存”，而在“有没有强制 Order”、“Offset 是否被恶意放大”、“COUNT 查询是否和主查询隔离”。缓存预热只是把问题从数据库转移到了缓存层，还多了一层不一致风险。
