Limit+Offset分页在GORM中易导致数据重复/丢失且性能随Offset增大急剧下降，应优先采用基于主键或时间戳的游标分页，并确保排序字段有索引。
为什么 Limit + Offset 分页在 GORM 中容易出错
直接用 Limit 和 Offset 做分页，看似简单，但实际会遇到两个硬伤：一是数据变动时（比如新插入或删除记录），同一页可能重复或漏掉数据；二是 Offset 越大，数据库扫描行数越多，MySQL/PostgreSQL 性能断崖式下降。GORM 本身不提供“游标分页”原生支持，所以得靠手动控制查询逻辑。
常见错误现象：Offset(1000).Limit(20) 在百万级表上执行超慢，或者翻到第50页时发现某条记录突然消失。
- 不要把
Offset当作页码乘以每页数量后直接传入，尤其在高并发写入场景下不可靠 - 如果业务允许，优先用基于主键或时间戳的游标分页（例如
WHERE id > ? ORDER BY id LIMIT 20） - GORM v2 的
Scopes可封装分页逻辑，但底层仍是 SQL 拼接，需确保排序字段有索引
用 Paginate 第三方插件快速实现传统分页
社区最常用的是 github.com/lestrrat-go/paginate 或更贴合 GORM 的 github.com/guregu/dynamo 风格封装 —— 但真正轻量又可靠的，是 github.com/boombuler/pagination 或自行写的 Paginate 函数。不过更推荐直接用 github.com/joshbetz/pagination（专为 GORM v2 设计）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go get github.com/joshbetz/pagination - 调用前必须指定
ORDER BY，否则 GORM 无法保证分页顺序稳定，例如db.Order("id ASC") - 分页结构体要包含
Total字段，它会触发一次COUNT(*)查询，注意避免在无 WHERE 条件时全表统计 - 示例：
var users []User<br>pagination := pagination.Paginate(db, &users, page, pageSize)<br>return users, pagination, nil
手写游标分页：绕过 OFFSET 的安全做法
当数据实时性要求高、写入频繁，或需要“无限滚动”加载时，OFFSET 分页必须放弃。游标分页依赖上一页最后一条记录的排序字段值（如 id 或 created_at），每次查询只扫增量数据。
关键点：
- 必须有确定的、带索引的排序字段，且该字段值全局唯一或严格单调（
id最稳妥，created_at在高并发下可能重复） - 查询语句形如：
SELECT * FROM users WHERE id > ? ORDER BY id LIMIT 20，GORM 写法：db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端需传递
last_id（不是页码），后端不做校验直接用于 WHERE，避免越界或空结果陷阱 - 首次请求用
ORDER BY id ASC LIMIT 20，下一页传回的users[len(users)-1].ID即为下一轮lastID
分页总数统计的性能陷阱与替代方案
db.Model(&User{}).Count(&total) 看似标准，但在大表 + 复杂 WHERE 条件下，COUNT 查询可能比主查询还慢。很多场景其实不需要精确总数 —— 比如用户只关心“有没有下一页”，而非“一共有多少页”。
- 用
LIMIT + 1判断是否有下一页：查n+1条，返回前n条，若结果长度为n+1，说明存在下一页 - 对总数精度要求不高时，可用 MySQL 的
EXPLAIN行数估算，或 PostgreSQL 的pg_class.reltuples，但仅限无 WHERE 的粗略参考 - 如果必须返回总数，且条件固定，考虑用物化视图或定时更新的统计表缓存
count结果
游标分页天然不依赖总数，这也是它在 API 设计中越来越主流的原因 —— 不是功能少，而是更务实。
