sql.Rows 必须显式调用 Close() 才能归还连接，Next() 结束不释放连接；defer 应紧随错误检查后、Next() 前注册，否则易提前关闭或失效；不调用将导致连接池耗尽、超时及锁冲突。
sql.Rows 必须显式调用 Close()，不是因为 Next() 走完了就自动释放
很多人看到 for rows.Next() { ... } 循环结束，就以为连接已归还——其实完全不是。Go 的 *sql.Rows 是一个流式迭代器，Next() 只是推进内部游标，不涉及连接生命周期管理。Close() 才是真正把底层数据库连接放回连接池的唯一动作。漏掉它，连接就被长期占用，池子很快枯竭。
defer rows.Close() 放错位置会导致提前关闭或根本没执行
常见错误是写成这样：
rows, err := db.Query("SELECT ...")
if err != nil {
return err
}
defer rows.Close() // ❌ 危险：如果 rows 是从其他函数返回的，或被包装进接口，defer 会立即执行（在 Query 返回后、甚至还没开始 Next 前）
正确姿势是：在确认 rows 非 nil 且无初始错误后，立刻注册 defer：
- 必须放在
if err != nil检查之后、任何rows.Next()之前 - 不能放在函数开头或封装层外，否则可能因作用域提前退出而失效
- 如果
rows被返回给调用方（比如作为接口字段），defer就完全不可靠，必须由接收方负责关闭
不关 rows.Close() 的典型表现和排查线索
现象不是报错，而是缓慢恶化：
-
db.Query()开始卡住、超时，日志里出现sql: connection is busy或context deadline exceeded -
netstat -an | grep :3306（MySQL）或lsof -i :5432（PostgreSQL）显示大量 ESTABLISHED 连接堆积 - SQLite 报
database is locked，尤其在事务中混用db.Query()和tx.Exec()时 -
rows.Err()在循环结束后不为 nil，但你没检查——说明扫描过程出错，rows.Close()更不能跳过
为什么 QueryRow() 不用关，而 Query() 必须关
这是设计差异，不是疏忽：
-
db.QueryRow()内部调用Query()后，立刻执行rows.Next()+rows.Close()，封装成单行语义，对用户透明 -
db.Query()明确面向多行结果集，需用户控制迭代节奏（比如分页读取、流式处理），所以释放权交还给开发者 - 误用
db.Query()处理 RETURNING（如 PostgreSQL upsert）会导致id恒为 0——因为没调Next()就直接Scan()，静默失败；这种场景必须用QueryRow()
rows 是本地变量、且没跨函数边界传递，defer rows.Close() 放在错误检查后就是最简可靠的方案；一旦涉及返回、缓存、复用，就得手动管理，且必须在所有退出路径上覆盖。 
