GORM 无真正流式查询，FindInBatches 是唯一生产可用的防 OOM 方案；Rows() 仍触发模型内存分配与反射，无法避免单行大内存开销，且丢失 GORM 语义与错误统一处理。
直接结论：GORM 本身不提供真正的“流式查询”，FindInBatches 是唯一可控、生产可用的防 OOM 查询方式；所有试图用 Rows() + Scan() 手动流式读取的方案，都绕不开 GORM 模型层的内存分配和反射开销，反而更难控制。
为什么不能用 Rows() 做“流式”防 OOM？
很多人看到 db.Raw("SELECT * FROM logs").Rows() 就以为能像 JDBC 的 ResultSet 那样逐行消费——但实际不是。GORM 的 Rows() 返回的是原生 *sql.Rows，一旦调用 Scan() 填充结构体，它仍会为每行完整分配模型字段内存，并走一遍反射赋值。如果模型含 []byte、string（尤其是大文本字段），或嵌套结构体，单行内存可能达几 MB，10 万行照样 OOM。
-
Rows()只避开 GORM 查询构建和事务封装，不跳过模型实例化 - 无法复用
Preload或关联逻辑，业务代码要重写一遍 JOIN 和反序列化 - 错误处理分散：
Rows.Err()、Scan()错误、类型不匹配 panic 都得单独兜底
FindInBatches 是唯一靠谱的批量节流方案
FindInBatches 不是“流式”，而是“可控分批”：它把大查询切分成固定 size 的子查询，每次只加载一批进内存，处理完自动 GC，避免单次堆内存爆炸。关键在于它仍走 GORM 正常查询路径，保留预加载、钩子、软删除等语义，且每批都是独立事务上下文。
- batch size 必须显式指定，建议从
500起调，根据单条记录平均大小反推（如日志平均 2KB，batch=500 → 单批约 1MB） - 必须传入指针切片变量，例如
var logs []Log，然后db.Where("created_at > ?", t).FindInBatches(&logs, 500, handler) - handler 函数内务必清空切片引用：
logs = logs[:0]，否则底层数组不会被 GC，内存持续增长 - 不要在 handler 外部复用同一个切片变量——GORM 内部会重新分配底层数组，外部变量可能指向旧内存
配合 FindInBatches 必做的三件事
光靠 FindInBatches 不够，它只是节流阀，地基还得自己打牢：
- 模型定义必须精简：
Log结构体只留导出需要的字段，删掉所有未使用的gorm.Model嵌入、钩子函数、冗余标签（如json:、form:） - 禁用默认事务：
SkipDefaultTransaction: true，否则每批都开事务，长查询易锁表、拖慢数据库 - 主键必须单调递增且有索引：GORM 内部用
WHERE id > ? ORDER BY id LIMIT ?分页，若主键乱序或缺失索引，会退化成全表扫描+临时排序，CPU 和 I/O 双爆
真正的大数据导出场景，该换思路
当单次导出超 100 万行、或字段含大文本/JSON/BLOB 时，FindInBatches 的反射和内存分配成本依然可观。此时应跳出 ORM 思维：
- 用
db.Raw().Rows()+sql.NullString等基础类型手动 Scan，跳过结构体分配，自己拼 CSV 行 - 导出到文件时，用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_APPEND)配合固定缓冲区bufio.NewWriterSize(f, 1<code>1024</code>*1024)，避免bytes.Buffer累积 - 加进度通知：在 batch handler 里发 channel 或更新 Redis 计数器，别等全跑完才告诉前端“好了”
最常被忽略的一点：FindInBatches 的 handler 函数里，任何对 tx 的额外查询（比如查用户昵称）都会让这批变成 N+1——它只保证本批主表数据分页，不约束你写的业务逻辑。
