应采用游标分页而非Limit+Offset，因排行榜数据高频变动时，Offset分页会导致漏条目、重复显示、跳页；游标分页基于score DESC, id DESC等稳定排序字段，通过where条件续查，避免扫描丢弃，且需索引覆盖、游标加密防篡改。
高频变动排行榜（如实时点赞榜、交易热榜、弹幕热度榜）用 GORM 做分页，不能直接套用 Limit+Offset —— 数据滚动时会漏条目、重复显示、跳页，本质是「快照分页」不适用于「持续写入+排序变化」的场景。
为什么 Offset 分页在排行榜里会出错
假设榜单按 score DESC, updated_at DESC 排序，每页 20 条：
- 用户 A 看第 1 页（offset=0），拿到 top20；此时某条数据 score 突然飙升，挤进前 20
- 用户 B 紧接着请求第 2 页（offset=20），但因 top20 已变动，原第 21 名可能被顶到第 19 名，导致它既没出现在第 1 页，也没出现在第 2 页（漏掉）
- 更糟的是，如果多条记录 score 相同，GORM 用
Offset无法保证相同 score 下的稳定排序顺序（除非显式加唯一二级排序字段） -
Offset越大，扫描行数越多，MySQL 执行计划容易退化为全表扫描（尤其当score没覆盖索引时）
用游标分页（Cursor-based Pagination）替代 Offset
核心思路：不记“第几页”，而记“从哪条继续往后取”。依赖一个单调、唯一、可索引的排序字段组合，例如：score, id（id 作为 score 相同时的兜底排序）
- 首次请求不带游标，查 top20：
db.Order("score DESC, id DESC").Limit(20).Find(&users) - 返回结果末尾的
user.Score和user.ID拼成游标，比如"98765|10042" - 下一页请求传该游标，解析后构造条件：
db.Where("score - 必须确保
score, id组合上有联合索引：CREATE INDEX idx_score_id ON user (score DESC, id DESC) - 注意：若排序字段允许 NULL，需额外处理（如用
COALESCE(score, 0)包裹，或禁止 NULL）
如何应对 score 高频更新导致的游标失效
当某条记录 score 被反复修改，它在排序中的位置剧烈跳动，可能导致游标查询返回空或错乱。这时需加一层防御：
- 每次游标查询后，检查实际返回条数 —— 若少于预期（如只返回 12 条），说明中间有大量数据插入/更新，应降级为“基于时间窗口的近似分页”（例如只查过去 5 分钟内变更的数据）
- 对 score 更新操作加轻量锁或队列（如用 Redis INCR + Lua 脚本限频），避免单条记录 1 秒内被更新 >5 次
- 客户端不暴露原始游标，服务端生成加密签名游标（如
base64(score|id|timestamp|signature)），防止恶意篡改和重放 - 游标过期时间设为 30 秒，超时则要求客户端重新拉首页（避免长时间持旧游标导致数据陈旧）
游标分页不是银弹：它要求排序字段足够“稳”，且索引能覆盖查询路径；一旦业务允许按时间范围切片（比如“今日热榜”“小时榜”），比纯全局游标更可控、更容易缓存和预计算。
