游标分页不能用OFFSET+LIMIT，因其需全扫描并丢弃前N行，大数据量时性能骤降且高并发下易漏数或重复；必须用确定性排序（如created_at+id）配合WHERE范围查询实现稳定锚定。
游标分页为什么不能直接用 Offset + Limit
因为 Offset 是物理跳过行，数据库必须真实扫描并丢弃前 N 行——数据量一上十万，OFFSET 100000 就会拖慢查询到秒级，且并发写入时结果不可重现。这不是 GORM 的限制，是 SQL 执行模型决定的。你看到“翻页漏记录”或“同一页两次请求结果不一致”，八成没加确定性排序，或者还在用 Offset 做用户端无限滚动。
游标分页必须带确定性排序和索引
游标分页本质是“从上一页最后一条往后取”，所以 WHERE 条件必须能精准锚定起点，且排序必须稳定。常见错误是只写 Order("created_at DESC")，但高并发下毫秒级时间戳重复很常见，导致顺序不确定。
- 最稳组合：
Order("id ASC")+WHERE id > ?（主键单调递增，索引天然覆盖） - 时间优先场景：
Order("created_at DESC, id DESC")+WHERE created_at - 必须给排序字段建联合索引，例如
INDEX idx_created_id (created_at, id)，否则照样慢 - 别在游标条件里混用
OR和函数（如DATE(created_at)），会破坏索引使用
前端传 last_id 还是 last_cursor？别转译
游标分页不是把页码转成偏移量，而是让前端原样透传上一页最后一条的排序字段值。后端不做任何计算或转换，只做类型校验和安全拼接。
- 首次请求不带游标参数，查
db.Order("id ASC").Limit(20).Find(&users) - 后续请求必须带
last_id（或cursor），且值来自上一页users[len(users)-1].ID - 若传的是字符串型
last_id，用strconv.ParseUint而非Atoi，避免负数溢出 panic - 非法游标（如空、负数、超长数字）应直接返回
400 Bad Request，不 fallback 到第一页
Count 总数在游标分页里通常不该返回
游标分页天然不支持“总页数”，因为无法高效算总数；强行 COUNT(*) 会抵消掉游标带来的性能优势。多数业务真正需要的只是“有没有下一页”。
- 查
Limit(21)，如果返回 21 条，说明还有下一页，截掉第 21 条后返回 20 条 +has_next: true - 如果只返回 ≤20 条，说明到底了，
has_next: false - 真要总数（比如后台管理），单独走传统
Count查询，但必须用新会话：db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 复杂 JOIN 场景下，
Count容易不准，宁可手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE ...) AS t").Scan(&total)
