findinbatches比limit+offset快得多，因其采用主键游标（where id > ?）而非扫描跳过前n行，避免offset导致的性能断崖；前提需单调递增无空洞主键且显式order by id，否则可能漏数据、报错或退化为普通分页。
FindInBatches 为什么比 Limit+Offset 快得多
因为 FindInBatches 不跳数据，而是用主键游标推进。当 Offset 达到几十万甚至百万时，LIMIT 100 OFFSET 999900 要让数据库扫描并丢弃前 999900 行，而 WHERE id > 50000 ORDER BY id LIMIT 100 可直接走主键索引定位起点，性能基本恒定。
关键前提是：必须有单调递增、无空洞的主键（如自增 id），且查询必须按该字段升序排序。GORM 默认会补 ORDER BY id，但如果你显式写了 ORDER BY created_at，它就不会自动加，这时 FindInBatches 会退化为普通分页，甚至报错。
- 不指定
ORDER BY：GORM 自动加ORDER BY id - 显式指定非主键字段排序（如
ORDER BY name）：FindInBatches会 panic，提示“batch query requires order by primary key” - 主键不是整型或有空洞（如 UUID、软删除后 ID 不连续）：游标逻辑失效，结果可能漏数据或重复
FindInBatches 的调用姿势和常见报错
正确写法要带回调函数，不能只写查询链式调用：
db.Where("status = ?", "active").FindInBatches(&users, 100, func(tx *gorm.DB, batch int) error {
// 处理每一批 users
return nil
})
容易踩的坑：
- 忘记传回调函数：编译不报错，但
FindInBatches不执行任何查询，users保持空切片 - 在回调里直接用
db而不是参数传入的tx：导致并发 batch 混用同一个 DB 实例，事务/上下文错乱 - 回调返回非
nilerror：整个批次中断，后续 batch 不再执行（这是设计行为，不是 bug） - 传入 batch size ≤ 0：GORM 内部会 panic，错误信息是 “batch size must be greater than 0”
什么时候不该用 FindInBatches
它不是万能替代品，以下场景建议退回传统分页或换方案：
- 需要精确知道总条数（
total）做页码导航：FindInBatches不提供 count，你得额外查一次SELECT COUNT(*) - 前端要求跳转任意页（比如输入“第 87 页”）：游标分页天然不支持随机跳转，只能顺序下一页
- 排序字段不是主键且无法加唯一索引（如多字段组合排序 + 时间戳）：游标难以构造稳定偏移条件，容易漏/重
- 数据实时性极高，且主键有大量删除/插入（ID 空洞严重）：游标基于上批最大 ID 推进，空洞会导致跳过部分记录
此时更稳妥的选择是 Limit+Offset 配合缓存 count，或用时间范围分页（如 WHERE created_at > ?）。
底层游标逻辑怎么影响你的代码结构
FindInBatches 的每次回调都是一次独立事务上下文，意味着：
- 不能在回调外提前声明变量并期望跨 batch 累加（如
var allUsers []User），必须在回调内处理或传指针进去 - 如果要批量更新这批数据，得在回调里用
tx.Model(&User{}).Where(...).Update(...)，而不是用外部db - 日志或监控需在回调内打点，否则看不到单批耗时；出错时也得靠
batch参数定位是第几批挂了 - 若某批失败需重试，GORM 不提供断点续传机制，你得自己记录上一批最大
id值并手动构造下一批查询
真正用起来，它不像一个“封装好的分页函数”，而更像一个受控的流式处理器——控制权在你手上，但也意味着更多责任。
