go中无通用迭代器接口，database/sql.rows需手动调用next()和scan()流式读取，及时close()防连接泄漏，避免反射开销与分页性能陷阱。
Go 里没有内置迭代器接口，range 不是万能的
Go 语言标准库不提供类似 Java Iterator 或 Python __iter__ 那样的通用迭代器抽象。你不能对任意结构体直接写 for item := range obj——除非它实现了 Go 的「可 range 类型」：数组、切片、map、channel、字符串。数据库游标显然不属于其中。
所以想用「迭代器模式」遍历百万级结果，得自己封装状态和移动逻辑，而不是幻想有个 Next() 方法自动帮你推进。
-
database/sql.Rows本身就是游标式结构：调用rows.Next()才真正从底层驱动拉下一行，配合rows.Scan()解包，这才是真正的逐行流式读取 - 别提前把所有结果
rows.Columns()+rows.SliceScan()拉进内存——那会瞬间吃光几百 MB，甚至触发 OOM - 注意
rows.Err()必须在循环结束后检查：rows.Next()返回false时，错误可能藏在rows.Err()里，不是nil
sql.Rows 的生命周期和连接池绑定很紧
很多人以为 rows 是个纯数据容器，其实它强依赖底层 *sql.Conn，而后者来自连接池。一旦你没及时 rows.Close()，连接就一直被占着，很快耗尽 db.SetMaxOpenConns() 设置的上限，后续查询卡死在 acquireConn 阶段。
- 必须在
for rows.Next()循环结束后立刻调用rows.Close()，哪怕中间break或return，也要用defer rows.Close()包住 - 不要把
rows传给其他 goroutine 去消费——不同 goroutine 并发调用Next()会竞争内部状态，行为未定义 - 如果需要跨 goroutine 分发数据，先用 channel 中转，且确保
rows在本 goroutine 内完成关闭
处理百万行时，Scan() 的字段绑定方式影响性能和稳定性
每调用一次 rows.Scan()，Go 就要反射解析目标变量类型、做类型校验、分配临时缓冲区。对百万行来说，这点开销会被放大。
立即学习“go语言免费学习笔记（深入）”；
- 优先用具体类型指针，比如
var id int64; var name string; rows.Scan(&id, &name)，避免interface{}+ 类型断言 - 别用
sql.NullString等包装类型除非真要区分 NULL 和空字符串——它们额外增加字段判空逻辑和内存分配 - 如果字段多且固定，考虑用
Rows.Scan()配合结构体字段地址数组（[]interface{}），但要注意每次循环都要重置指针值，否则第二次扫描会写错位置
游标分页 vs. 游标流式读取，别混淆概念
业务常说的「游标分页」（比如用 last_id 或 created_at 做 where 条件）和数据库驱动层的「游标遍历」（sql.Rows）是两回事。前者是应用层翻页策略，后者是底层数据拉取机制。
- 用
LIMIT OFFSET做分页查百万级数据？跳过前 99 万行时，MySQL 仍要扫描并丢弃它们，I/O 和 CPU 成倍增长 - 真要分页，优先用无状态游标：
WHERE id > ? ORDER BY id LIMIT N，配合上一页最后的id值 - 但如果目标只是「全量导出/清洗/聚合」，就别分页，直接用
rows.Next()流式读，省掉 N 次 round-trip 和重复排序
最常被忽略的一点：驱动返回的 rows 默认不支持 Seek() 或 Reset()，也没法倒带。游标只向前，且不可重用——想重读，只能重新执行查询。
