Limit+Offset分页在GORM中易导致数据重复/丢失且性能随offset增大急剧下降，应优先采用基于主键或时间戳的游标分页，并确保排序字段有索引。
直接用 Limit 和 Offset 实现分页，能跑但不安全；高偏移、高并发、数据频繁变更时，必须换游标分页。
为什么 Limit + Offset 在 GORM 中容易出错
OFFSET 不是“第几页”的映射，而是数据库扫描跳过的物理行数。当表中存在插入/删除操作时，同一页可能重复或漏掉记录；更严重的是，OFFSET 越大，MySQL/PostgreSQL 扫描的行越多，OFFSET 10000 LIMIT 20 可能比全表扫描还慢。
- 常见错误现象：
page=50&page_size=20返回空数组，或某条记录在第 49 页和第 51 页都出现 - 性能断崖点通常出现在 OFFSET > 5000（MySQL）或 > 10000（PostgreSQL），取决于索引覆盖程度
-
Count(&total)查询必须独立执行，不能复用带Limit/Offset的链式 DB 实例，否则条件残留或清空逻辑混乱 - 没加
Order("id ASC")的分页结果不可预测——数据库不保证无序查询的返回顺序
怎么安全地用 GORM 做传统分页
适用于数据变动少、页码靠前（page <= 20）、总记录数稳定（如后台管理类场景）。
- 参数校验必须做：
page至少为 1，page_size严格限制上限（比如min(p.PageSize, 100)），避免恶意传page_size=10000 - 排序字段必须有索引，且显式写在
Order()中，例如db.Order("created_at DESC").Order("id DESC")（复合索引需匹配） - 总数查询要单独构造条件一致的 DB 实例：
db.Where("status = ?", "active").Model(&User{}).Count(&total)，而不是在同一个链上连写Count().Limit().Find() -
Offset()必须在Limit()前调用（GORM v2 兼容，但语义清晰起见建议固定顺序）
什么时候该切游标分页（Cursor-based Pagination）
当接口面向用户端（如 App 无限滚动）、数据实时写入频繁、或页码可能远超 100 时，游标分页不是“可选优化”，而是必须项。
立即学习“go语言免费学习笔记（深入）”；
- 核心逻辑是传递上一页最后一条记录的排序字段值，例如前端首次请求不带参数，后端返回
users[19].ID作为next_cursor；下一次请求带?cursor=12345，后端生成WHERE id > 12345 ORDER BY id ASC LIMIT 20 - 排序字段必须全局唯一、单调递增（
id最稳妥；created_at在高并发下可能重复，需补id作二级排序） - 数据库对应字段必须有索引，且 WHERE + ORDER BY 能命中同一索引（例如
INDEX (id)或INDEX (created_at, id)） - 不要校验
cursor是否真实存在——它只是游标值，WHERE id > ?查不到结果就返回空数组，前端停加载即可
别踩这些 GORM 分页坑
很多问题不是代码写错，而是对 GORM 行为理解偏差导致的隐性故障。
-
Paginate不是 GORM 内置方法，所有第三方插件（如github.com/joshbetz/pagination）底层仍是Limit/Offset，不会自动规避排序缺失或参数越界 -
Preload不能和分页混用：写db.Preload("Orders").Limit(10).Find(&users)会先查 10 个用户，再为每个用户发 N 条SELECT * FROM orders WHERE user_id IN (?)，实际加载远超 10 条关联数据 -
Find(&list).RowsAffected返回的是本次查询条数（即page_size），不是总数；想省一次COUNT查询？别试 - 用
ShouldBindQuery绑定结构体时，非法参数（如page=abc）会直接返回 error，别用c.DefaultQuery默默 fallback——这会让前端以为参数合法，后端却按默认值执行，造成行为不一致
最常被忽略的一点：游标分页的首次请求和后续请求逻辑不对称，cursor 参数无法复用传统分页的 page 语义，前端必须区分两种模式；而传统分页的 Offset 计算一旦漏了 page >= 1 校验，page=0 会传负数给 Offset()，在某些驱动下 panic。
