findinbatches必须显式指定order by，因其底层依赖游标分页（where id > last_id），仅当主键为单调递增整型id时gorm才自动补order by id；主键为uuid、created_at或存在重复值时，不加或错加order by会导致数据重复、遗漏或行为未定义。
FindInBatches 是 GORM 处理海量数据最直接、最稳妥的批处理函数，但它不是“开箱即用”的万能解药——用错参数或忽略约束，照样 OOM 或查漏数据。
为什么 FindInBatches 必须显式指定 ORDER BY？
GORM 的 FindInBatches 底层依赖游标分页（WHERE id > last_id），而非 offset/limit。它默认补 ORDER BY id，但仅当主键是 id 且类型为整型时才可靠。如果表主键是 uuid、created_at 或复合主键，必须手动加 ORDER BY，否则行为未定义：
- 不加
ORDER BY且主键非单调递增 → 下一批可能重复或跳过数据 - 用
ORDER BY created_at但该字段有重复值 → 同一时间戳的多条记录可能被漏掉（WHERE created_at > '2026-01-01' 不保证覆盖全部） - 正确写法：
db.Order("id ASC").FindInBatches(&users, 1000, fn)
FindInBatches 的回调函数里不能直接修改切片长度
回调函数接收的 users 切片由 GORM 复用底层缓冲，每次调用都指向同一块内存地址。常见错误是：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在回调里做
users = append(users[:0], ...)→ 破坏 GORM 内部状态，下一批数据可能读错 - 把
&users[0]传给 goroutine 异步处理 → 下一批覆盖后，异步逻辑读到脏数据 - 正确做法：需要深拷贝时，用
copied := append([]User(nil), users...)；若只读，直接遍历即可
批次大小设多少才不崩？看字段宽度，不是拍脑袋
1000 条听起来合理，但实际取决于单条记录内存占用。一个含 TEXT 字段的用户日志，每条平均 2KB，1000 条就是 2MB 内存/批次。百万级数据下，光中间切片就吃掉 2GB+。
- 先估算单条平均大小：
SELECT pg_size_pretty(pg_total_relation_size('logs')) / COUNT(*) FROM logs LIMIT 1;（PostgreSQL） - 目标每批次内存 ≤ 4MB → 若单条 1.5KB，则批次上限 ≈ 2500；若含 JSONB 字段，可能压到 300
- 别用
len(users)判断是否结束：最后一批可能不足设定值，但仍是有效数据
想并发处理批次？别在回调里起 goroutine
FindInBatches 本身是同步阻塞的，回调函数执行完才查下一批。如果在回调里直接 go processBatch(users)，所有批次会几乎同时启动 goroutine，瞬间拉起数百个并发，数据库连接池立刻打满。
- 真正可控的做法：回调中把
users推入带缓冲 channel（如make(chan []User, 8)），另起固定数量 worker 消费 - worker 数量建议设为
runtime.NumCPU()，避免调度器过载 - 更稳的选择：用
db.Session(&gorm.Session{PrepareStmt: true})复用预编译语句，降低单次查询开销
FindInBatches 不支持事务自动延续。如果你需要跨批次强一致性（比如边查边删），必须自己控制事务生命周期，并确保每个批次都在同一 tx 内完成 —— 而不是靠回调函数里的 db.Transaction() 单独开事务。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
