分页必须显式声明order，否则结果不可靠；应优先用order("id asc")，复合排序需配对应索引；offset必须在limit前调用，并校验page和size参数合法性。
分页必须显式写 Order，否则结果不可靠
没加 Order 的分页查询，在 MySQL 或 PostgreSQL 中返回顺序完全不确定。同一次请求可能拿到不同顺序的数据，翻页时漏掉或重复某条角色记录是常态，不是偶发 bug。
真实业务中角色表常按 created_at 或 id 排序，必须显式声明：
-
Order("id ASC")最稳妥，id是主键，天然有索引且唯一 - 若按状态+创建时间复合排序，得用
Order("status ASC").Order("created_at DESC")，并确保数据库有对应复合索引 - 千万别写
Order("name")这类可能重复的字段作主排序，否则 OFFSET 会错位
Offset 和 Limit 顺序不能反，参数要校验截断
Offset 必须在 Limit 前调用，GORM v2 虽兼容互换，但语义上 Offset((page-1)*size).Limit(size) 才符合直觉，也避免跨版本行为差异。
前端传 page=3&size=20，后端不能直接算 Offset(40) —— 用户可能传 page=-1、size=9999，导致全表扫描甚至 DB 拒绝连接。
- 用
c.ShouldBindQuery(&p)绑定结构体，比手动c.Query()更安全 -
page小于等于 0 时强制设为 1；size超过配置上限（如 100）就取min(p.Size, 100) - 计算 offset 时先做整数检查：
if p.Page ，再算 <code>offset := (p.Page - 1) * p.Size
总数查询必须独立构造 *gorm.DB 实例
前端需要总条数渲染页码控件，但 Count(&total) 不能和列表查询共用同一个链式 *gorm.DB 实例。否则 Where 条件残留、Limit/Offset 污染会导致统计不准。
正确做法是另起一个干净实例，复用相同查询条件：
// 列表查
db.Where("status = ?", "active").Order("id ASC").Offset(offset).Limit(size).Find(&roles)
<p>// 总数查（单独 new 一个）
var total int64
db.Model(&Role{}).Where("status = ?", "active").Count(&total)
</p>
注意：Model(&Role{}) 是关键，它清空了之前所有链式操作，只保留 WHERE 条件。
高并发写入场景下，Limit+Offset 分页会丢数据
当角色表频繁增删（如后台批量导入/禁用），第 50 页可能跳过刚插入的一条记录，或把已删除的角色又查出来。这不是 GORM 的问题，而是数据库物理扫描机制决定的 —— OFFSET 4999 表示跳过前 4999 行，但这些“行”在两次查询之间可能已变动。
真正可靠的方案是游标分页，尤其适用于角色管理后台的「导出全部」「批量操作」等场景：
- 前端传上一页最后一条角色的
id（比如cursor=12345） - 后端查：
Where("id > ?", cursor).Order("id ASC").Limit(20) - 必须确保
id字段有索引，且排序字段与游标字段一致 - 首次请求可不带
cursor，用Order("id ASC").Limit(20)启动
游标分页无法跳转任意页码，但能彻底避开 OFFSET 的数据漂移和性能坍塌问题 —— 百万级角色表翻到第 1000 页依然稳定在毫秒级。
