应缓存静态榜单等读多写少场景，键用确定性拼接，值用json_encode序列化，高偏移量改用游标分页防击穿，避免LIMIT OFFSET性能陷阱。
缓存分页结果前先确认是否真能缓存
分页查询缓存不是万能的，尤其当数据实时性要求高、用户登录态影响结果（如权限过滤）、或 ORDER BY 字段频繁更新时，缓存反而导致脏数据。真正适合缓存的是「静态榜单」「商品分类列表」「博客归档页」这类读多写少、排序稳定、无个性化逻辑的场景。
关键判断点：
• 分页 SQL 中不含 WHERE user_id = ? 或 session_id 类动态条件
• 排序字段（如 created_at）更新频率低于缓存 TTL（比如每小时更新不到 10 次）
• 总记录数 COUNT(*) 不随每次请求重算（应单独缓存或用近似值）
用 Redis 缓存分页数据块而非整页 HTML
别把 render_page_html() 的输出直接塞进 Redis——HTML 体积大、难以复用、无法按需更新某一页。正确做法是缓存「数据块」：即 SELECT id, title, updated_at FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 40 返回的数组。
实操建议：
• 键名用确定性拼接，例如 "page:posts:by_created:20:40"（表示每页 20 条、第 3 页）
• 值序列化用 json_encode()，避免 serialize() 的 PHP 版本兼容问题
• 设置 TTL 略高于业务容忍延迟，比如 600 秒（10 分钟），并配合「惰性删除 + 主动刷新」策略
• 若总条数变化，只删 "count:posts:by_created" 键，不影响已有分页数据块
立即学习“PHP免费学习笔记（深入）”；
跳页时避免缓存击穿和雪崩
用户猛点第 1000 页，而该页从未被访问过，此时大量并发请求会同时穿透缓存去查 DB，还可能触发重复缓存写入。这不是理论风险，真实日志里常看到 "SELECT ... LIMIT 20 OFFSET 19980" 突增。
