FindInBatches能避开OOM而Find+Limit/Offset不能，根本原因是前者为游标式推进（基于主键范围查询，跳过成本O(1)），后者为跳过式扫描（需逐行遍历前Offset条记录）；当Offset超10万时，PostgreSQL常因buffer scan耗尽内存或超时，直接触发应用层OOM。
为什么FindInBatches能避开OOM，而Find+Limit/Offset不能
根本原因在于查询机制不同：Find + Limit/Offset 是“跳过式扫描”，数据库必须逐行遍历前 Offset 条记录；而 FindInBatches 是“游标式推进”，每次基于上一批的主键（通常是 id）做范围查询，跳过成本为 O(1)。当数据量达百万级、Offset 超过 10 万时，PostgreSQL 常因 buffer scan 耗尽内存或超时，直接触发应用层 OOM——不是 Go 程序写得差，是 SQL 执行计划本身在拖垮内存。
FindInBatches 的正确调用姿势
关键不是“用了没”，而是参数和上下文是否合理：
-
batchSize建议设为 500–2000：太小（如 100）导致查询次数爆炸，连接池易耗尽；太大（如 10000）单批加载仍可能占满 GC 堆，尤其字段多或含text/jsonb类型 - 必须传入指针切片（如
&users），且每次回调内要清空切片内容，否则数据会累积；常见错误是声明var users []User后反复复用，未重置长度 - 避免在回调中对整个批次调用
tx.Save：它会生成 N 条 UPDATE，应改用tx.Save(&users)批量更新，或更优地用tx.Model(&User{}).Where("id IN ?", ids).Updates(...) - 若需关联数据（如用户+订单），绝不能在
FindInBatches外套Preload——这会让每批的 IN 查询膨胀成全量关联，回到两阶段膨胀的老路
配合连接与事务的硬性约束
再好的分批逻辑，也会被不匹配的数据库配置反杀：
-
MaxOpenConns必须严格控制：PostgreSQL 每连接约占 10MB 内存，设为 100 就可能吃掉 1GB；建议按公式(DB总内存 - 1GB) / 10反推，再除以服务实例数，单应用通常 ≤30 - 回调函数内务必用传入的
tx *gorm.DB，而非全局db：前者继承了当前批次的会话配置（如SkipDefaultTransaction: true），后者可能意外开启长事务，锁表或阻塞 WAL - 如需强一致性（如导出+归档），把整个
FindInBatches包在db.Transaction中反而危险——事务持续时间越长，锁持有越久；更稳妥的是用Repeatable Read隔离级别 + 时间点快照（PostgreSQL 的AS OF SYSTEM TIME不支持，但可用SELECT ... FOR SHARE配合业务校验）
真正容易被忽略的细节：字段裁剪与类型映射
即使用了 FindInBatches，如果查的是全字段模型，内存压力依然巨大。比如一个日志表含 content text 字段，单条 5KB，批量 1000 条就是 5MB——这还没算 Go 的 slice header 和字符串 header 开销。
- 始终用
db.Select("id", "user_id", "status")显式指定字段，禁止Find(&logs)直接查 struct - 对只读场景，用轻量结构体承接（如
type LogIDOnly struct{ ID uint }），GORM 会自动忽略未声明字段，比Select更省 CPU - PostgreSQL 的
jsonb字段默认被 GORM 解析为map[string]interface{}，极易引发深度嵌套 GC 压力；应显式定义结构体或用sql.RawBytes延迟解析
