FindInBatches 必须显式指定 Order，否则游标失效导致漏查、重复或顺序错乱；应按主键或复合字段确定排序，handler 中需单条处理、加 WHERE 条件更新，禁用批量 Save 和混用 CreateInBatches。
FindInBatches 必须显式加 Order，否则游标失效
很多人调用 FindInBatches 时只传切片和批次大小，漏掉 Order，结果数据漏查、重复或顺序错乱。这不是 GORM 的 bug，而是游标分页的底层逻辑决定的：它依赖确定性排序来定位“下一批起点”。没有 Order("id ASC") 或 Order("created_at DESC, id DESC")，数据库每次返回的行序都可能不同，FindInBatches 就没法知道该从哪继续。
常见错误现象：db.FindInBatches(&users, 100, handler) 返回总数比预期少 20%，且中间某批突然跳过几千条记录；或者同一批数据在两次请求中处理顺序不一致，导致幂等更新出错。
- 主键是自增整型（如
id）：必须写Order("id ASC")，不能省略方向 - 主键是 UUID 或时间字段为主：用复合排序兜底，例如
Order("created_at DESC, id DESC")，避免高并发下毫秒级时间重复导致游标偏移 - 禁用
Order("status ASC")这类低区分度字段——值重复太多，数据库内部排序不稳定 - 别信 “表没并发写入，不加 Order 也 OK” —— MySQL/PostgreSQL 标准不保证无序查询的行序一致性
handler 函数里不能批量 Save，要单条处理+条件更新
FindInBatches 的 handler 接收的是当前批次的切片（如 []User），但 handler 内部若直接调用 db.Save(&users)，会覆盖所有记录的主键、创建时间等字段，还可能因并发修改导致部分更新被跳过。它不是事务上下文的自动延续，而是一次独立的数据流喂入。
更危险的是：如果 handler 中执行了影响排序字段的操作（比如 db.Model(&u).Update("updated_at", time.Now())），后续批次的游标条件（如 WHERE id > ?）就可能失效，造成漏数据。
- 正确做法：遍历切片，对每条记录单独构造更新语句，例如
db.Where("id = ?", u.ID).Updates(map[string]interface{}{"status": "processed"}) - 更新前加 WHERE 条件兜底，防止 handler 被重复触发时误改已处理数据，如
.Where("status = ?", "pending") - 不要在 handler 里开新事务再 Commit ——
FindInBatches本身不提供事务包裹，需自行控制，且长事务易锁表 - handler 返回 error 会被捕获并中断整个批次流程，用于精准失败退出，不是用来做日志记录的
游标分页 ≠ 分页器，它不维护页码，只认 last_id
FindInBatches 不是传统分页接口，它不接受 page 和 pageSize，也不生成总页数。它的本质是“拉取一批、记下最后 ID、再拉下一批”，所以前端不能传 page=500，而必须传 last_id=123456，后端原样塞进 WHERE id > ? 条件里。
容易踩的坑：有人把 FindInBatches 当成黑盒分页器，在 handler 里偷偷改了数据的 id 或排序字段，下一批查询就从错误位置开始；或者前端传了非法 last_id（如负数、字符串），GORM 不校验，直接拼 SQL，结果查空或报错。
- 首次请求：不带
Where，只靠Order+Limit拉第一批，例如db.Order("id ASC").Limit(100).FindInBatches(...) - 后续请求：必须从上一批最后一条记录的
id字段取值，且该字段要有索引；UUID 场景下建议建(created_at, id)复合索引 - 后端收到
last_id后，先用strconv.ParseInt校验，非数字或负数直接返回 400，不静默转换 - 别用
Count()算总数——大数据量下它本身就会慢甚至超时，游标场景下总数本就无业务意义
CreateInBatches 和 FindInBatches 别混用同一张表的读写链路
一个典型翻车场景：用 FindInBatches 查订单，handler 里调用 db.CreateInBatches() 写日志表，结果发现订单查着查着就卡住、连接池耗尽。问题不在 CreateInBatches 本身，而在于它底层仍是串行 Exec，每条 INSERT 都占一个连接、一次 round-trip。当 handler 并发度高、批次小、日志量大时，数据库连接瞬间被占满。
更隐蔽的问题是：如果 FindInBatches 查询的表和 CreateInBatches 写入的表共享连接池（比如共用一个 *gorm.DB 实例），写操作慢会拖慢读操作的游标推进速度，导致整体吞吐下降。
- 读写分离：查订单用
readDB，写日志用独立的writeDB，连接池参数分开配置 - 日志类写入优先走异步 channel + worker 模式，而不是塞在 handler 里同步执行
-
CreateInBatches的batchSize需实测调优，MySQL 单批别超 200 行（尤其含 TEXT 或索引 > 3 个时），PostgreSQL 可到 1000+ - 别指望
FindInBatches自动帮你控制并发——它只管“拉”，“处理”和“存”得自己用 goroutine + channel 解耦，否则 CPU 和内存瓶颈立刻暴露
last_id 的来源必须 100% 可靠，一旦 handler 中修改了这批数据的排序字段，或数据库主键被人工调整，下一批就永远找不到起点。 
