rows遍历比find更适合超大数据集，因find一次性加载全部结果至内存，而rows逐行读取、内存恒定kb级，但需手动处理类型、空值、列序，并必须显式rows.close()防连接泄漏。
Rows 遍历为什么比 Find 更适合超大数据集
因为 Find 会把全部结果一次性加载进内存并映射成结构体切片，10 万行用户数据可能直接吃掉几百 MB；而 Rows 返回的是 *sql.Rows，逐行读取、按需解析，内存占用基本恒定在 KB 级别。
但代价是：你得自己处理字段类型、空值、列顺序，且必须显式关闭连接——漏掉 rows.Close() 会导致数据库连接泄漏，最终 too many connections 报错。
- 适用场景：导出报表、ETL 清洗、日志归档、跨库同步
- 不适用场景：需要随机访问某一行、要复用 GORM 钩子或关联预加载
- 性能影响：避免在
for rows.Next()循环里调用db.Create()这类 ORM 方法，会频繁创建事务上下文；改用db.Session(&gorm.Session{SkipDefaultTransaction: true})或原生Exec
怎么安全地用 Rows 扫描动态字段
Rows 不强制绑定结构体，适合字段不确定、或 SELECT 子句含聚合/别名/计算列的场景。关键点是先用 rows.Columns() 拿列名和类型，再用 rows.Scan() 按顺序填入 []interface{} 切片。
常见错误是变量类型与数据库列类型不匹配，比如 MySQL 的 TINYINT(1) 映射成 bool 会 panic，必须用 int8 或 sql.NullInt8。
- 扫描前务必检查
rows.Err()，否则循环结束后的错误会被忽略 - 用
sql.NullString、sql.NullInt64处理可能为 NULL 的列，避免 scan 失败 - 如果列名含下划线或大小写混用（如
user_name），rows.Columns()返回的是原始名，别硬编码结构体字段名去匹配
Rows + 原生 SQL 的参数安全写法
别拼接字符串传参，直接用 db.Raw() 的命名参数或问号占位符。GORM 的 Raw 支持两种风格，但 Rows 只认底层 *sql.Rows 接口，所以参数绑定逻辑和标准 database/sql 一致。
错误示例：db.Raw("SELECT * FROM logs WHERE level = '" + level + "'").Rows() —— SQL 注入高危。
- 推荐用问号占位符：
db.Raw("SELECT id, msg FROM logs WHERE level = ? AND created_at > ?", "ERROR", time.Now().Add(-24*time.Hour)).Rows() - 命名参数需配合
sql.Named（Go 1.19+）：db.Raw("SELECT * FROM users WHERE age > @min_age", sql.Named("min_age", 18)).Rows() - 注意：MySQL 驱动不支持命名参数，此时只能用问号；PostgreSQL 驱动支持，但命名参数名必须带
@或:前缀
Rows 遍历时怎么控制资源和错误传播
最易被忽略的是：遍历中途出错（比如网络中断、类型转换失败），rows.Next() 会返回 false 并设置内部 error，但如果不显式调用 rows.Err()，这个错误就丢了。
另一个坑是并发读取 —— *sql.Rows 不是线程安全的，不能多个 goroutine 同时调用 Next() 或 Scan()。
- 标准收尾模板：
defer rows.Close()放在if err != nil检查之后，确保无论是否出错都释放资源 - 循环内每轮都要检查
rows.Scan()的 error，尤其当字段数多、类型杂时 - 若需并发处理，应在
rows.Next()得到一行后，把该行数据拷贝进 channel，由 worker goroutine 消费，而不是共享rows实例
真正难的不是写对第一行 rows.Scan()，而是保证最后一行也正确 close、最后一个 error 被捕获、最后一个 NULL 被识别。Rows 是把双刃剑，自由度高，但所有资源生命周期和错误路径都得你自己画清楚。
