gorm中无scanrows方法，真实可用的是rows()配合手动rows.scan()或findinbatches()；rows()流式读取内存可控但须严格调用rows.close()、避免缓存全量结果；findinbatches基于游标分批、每批独立事务、内存占用稳定。
ScanRows 不是 GORM 原生方法，别被名字骗了
你搜 ScanRows 很大概率是看到某些封装库或博客误写的名称。GORM 官方 API 里没有这个函数——它既不是 db 的方法，也不在 Statement 或 FinisherAPI 中。真实可用的是 Rows() + 手动 rows.Scan()，或者用 FindInBatches() 分批拉数据。
用 Rows() 流式读取时内存是否可控
可控，但前提是严格遵守三件事：
-
rows.Close()必须调用，否则底层*sql.Rows连接不释放，连接池和内存都会持续增长 - 不要把整行 Scan 到大结构体再 append 到切片里；应该边 Scan 边处理，或只存关键字段
- 避免在
for rows.Next()内部做阻塞操作（如 HTTP 请求、文件写入），否则 rows 持有时间过长，数据库游标卡住
示例中常见错误写法：var results []User; for rows.Next() { var u User; rows.Scan(&u); results = append(results, u) }——这本质上退化成全量加载，和 Find() 没区别。
FindInBatches 为什么比 Rows() 更适合批量处理
因为它是“带事务上下文的分批”，不是单纯流式读取：
- 每批自动在一个子事务中执行，失败可单独回滚，不影响其他批次
- 批次大小由第二个参数控制（如
200），GORM 内部用主键范围或游标推进，避免OFFSET性能坍塌 - 传入的回调函数接收的是
*gorm.DB实例，可直接调用Save()、Update()等，无需手动管理 session 或 tx - 不会把整批数据长期 hold 在内存里：回调执行完，这批变量就可被 GC
注意：如果回调里做了 tx.Find(&batch)，那又绕回全量加载的老路——正确姿势是让 GORM 把当前批次的记录直接解到你传入的 slice 中。
Rows() 和 FindInBatches 的内存占用对比点
真正影响内存的不是「谁在读」，而是「谁在存」：
-
Rows()：单行 Scan 开销小，但如果你自己缓存所有结果（比如拼成 CSV 写磁盘前先 collect 全部），内存峰值 ≈ 全量数据 × 结构体大小 -
FindInBatches()：每批最多占用batchSize × 单条结构体大小，且批次间无强引用，GC 可及时回收 - 两者都可能因未关闭
rows或未 commit/rollback 事务导致连接泄漏，最终表现为内存缓慢上涨+数据库连接耗尽
最易被忽略的一点：GORM 的 Rows() 返回的是 *sql.Rows，它背后依赖驱动的实现细节（如 MySQL 驱动默认启用 buffered rows），有些场景下即使你没 Scan 完，驱动也可能已把部分结果集预加载进内存。所以别只看 Go 层代码，要结合 SHOW PROCESSLIST 和 innodb_buffer_pool_size 综合判断压力来源。
