用limit()和offset()实现分页，需校验参数、设默认值、加limit上限；count()须单独调用并复用条件链；排序应复合主键与时间戳；用scopes封装复用分页逻辑。
分页参数怎么传给 GORM？用 Limit() 和 Offset() 就够了
保险理赔系统里，审核任务列表动辄上千条，前端不可能一次拉完。GORM 的分页本质就是 SQL 的 LIMIT 和 OFFSET，但直接拼数字容易出错——比如 page=0 或 limit=0 会查出全表，page 超过总页数时返回空数组却不报错，前端可能卡在 loading 状态。
实际做法是：先校验参数，再转成整型，最后套进链式调用。别用字符串拼接或手动算 offset，GORM 已经封装好语义清晰的 API：
-
page默认值设为1，避免前端不传导致Offset(-10)这类 panic -
limit做硬性上限（比如lte=100），防止恶意请求拖垮数据库 - 计算
offset时统一用(page - 1) * limit，别写成page * limit - limit，后者在大数下可能溢出
为什么不能只查数据，还得查总数？Count() 必须单独走一次
前端分页控件要显示“共 XX 条”“第 X 页/共 Y 页”，这就要求后端必须返回总数。但 GORM 的 Find() 不带总数，得额外调一次 Count() ——而且不能复用同一个 *gorm.DB 实例的条件链，否则可能漏掉 where、join 等过滤逻辑。
常见错误是把 Count() 和 Find() 合并在一个事务里，或者用 Session(&gorm.Session{DryRun: true}) 模拟，这两种都不可靠。正确姿势是：
- 先构建完整查询条件（含 status、claim_id、reviewer_id 等业务过滤字段）
- 用该条件链调
Count(&total)，注意传的是指针 - 再用同一条件链调
Limit().Offset().Find() - 别省略
Error检查，Count()失败时 total 是 0，前端会误判为“没数据”
多级审核场景下，分页排序必须带 UpdatedAt 或 ID
保险理赔的审核流程常分初审、复审、终审，状态流转频繁。如果分页只按 CreatedAt 排序，当某条记录被多人同时更新，CreatedAt 不变但 UpdatedAt 变了，就会出现“同一页数据前后两次请求顺序不一致”，用户刷着刷着就漏单或重复看到。
解决方案是强制复合排序：主键 + 时间戳。例如：
db.Order("status ASC").Order("updated_at DESC").Order("id DESC")
这样即使 updated_at 相同（毫秒级并发），也能靠 id 保证稳定顺序。别用 ORDER BY RAND() 或纯 status，前者性能差，后者根本没法分页。
Scopes 怎么封装审核流分页？避免每个 DAO 都写重复逻辑
初审、复审、终审三个接口都要分页，但参数校验、总数统计、排序规则几乎一样。硬编码会导致改一处漏三处。GORM 的 Scopes 是解决这类问题的正解，不是炫技用的。
定义一个分页 scope 函数，接收 page 和 limit，内部做校验和链式调用：
func Paginate(page, limit int) func(db *gorm.DB) *gorm.DB {
return func(db *gorm.DB) *gorm.DB {
if page 100 { limit = 20 }
offset := (page - 1) * limit
return db.Limit(limit).Offset(offset)
}
}
使用时：db.Scopes(Paginate(p.Page, p.Limit)).Find(&items)。注意：scope 只负责分页，总数、排序、业务 where 条件得另外加，别塞进 scope 里搞成黑盒。
真正容易被忽略的是——scope 函数里的参数必须是值传递，不能闭包捕获 handler 层的上下文变量，否则并发时会错乱。比如把 c.Request.URL.Query() 直接塞进 scope，就等着线上翻车。
