Go database/sql 提前停止遍历 Rows 后为什么还要 Close

我第一次把“只取前几条记录”的查询封装成一个小函数时，直觉是读到数量就 break。后来回头看调用链，才意识到 *sql.Rows 不只是一个迭代器：它还承载结果集的关闭动作，以及遍历过程中延迟出现的错误。

所以答案很明确：只要 QueryContext 成功拿到了 Rows，就应该马上安排 Close；即使后面提前 break，也不能把释放责任交给“刚好读完”或驱动的隐式行为。正常读完时标准库可能自动关闭，但显式安排清理能覆盖提前返回、扫描失败和后续改动。

官方文档：https://pkg.go.dev/database/sql#Rows.Close

Rows 的接口目标不只有 Next

从调用方看，Rows 有三个紧密相关的职责：用 Next 推进结果集，用 Scan 取出当前行，用 Close 结束结果集生命周期。Err 则负责告诉我们遍历过程中是否出现了错误。

这几个动作的顺序很重要。break 只改变 Go 循环的控制流，并没有向调用方表达“结果集已经完成，也不需要再释放”。如果结果集仍有未读取的数据，驱动还可能保持与查询相关的状态，连接也不能立刻按调用方期望回到可复用状态。

这也是为什么我会把 Close 看成接口契约的一部分，而不是循环结束后的可选装饰：调用方决定只取几行，就同时承担结束这次结果集访问的责任。

拿到 Rows 后先安排一条稳定的 Close 路径

最小、最容易维护的写法，是在确认查询成功后立即 defer rows.Close()。这样无论是正常走出循环、提前 break，还是中途 return，清理动作都会执行：

func firstNames(ctx context.Context, db *sql.DB, limit int) ([]string, error) {
	// limit 是调用方的业务上限，避免为了取少量结果继续遍历整个结果集。
	if limit 

这里没有把 Close 写在 break 前面，因为那样很容易在未来增加另一个出口时漏掉清理。把责任绑定在函数作用域上，调用方的体验更稳定。

Scan 错误和 Rows.Err 要分开看

我实际排查过的一类问题是：代码只判断了 Scan 的返回值，却忽略了循环结束后的 Rows.Err。两者不是同一个位置产生的错误。

• Scan 负责把当前行转换到目标变量；类型不匹配、目标不可写等问题通常在循环体内返回。
• Next 负责推进结果集；驱动在推进过程中发现的读取错误，要在循环结束后通过 Rows.Err 读取。
• Close 表示结束结果集；某些驱动或多语句场景可能在关闭时报告额外错误，是否单独返回要结合业务契约。

如果业务只取前几行，循环因为数量达到上限而退出，此时没有继续调用 Next 的机会，通常应优先保证 Close 执行；如果你的驱动会把关闭阶段的重要错误返回出来，就不要无条件丢弃它。

什么时候用 defer，什么时候显式 Close

对一个函数只打开一组结果集、读取时间也短的场景，我倾向于 defer：它直接表达“这个函数拥有 Rows 的释放责任”，代码不会被多个出口拆散。

需要显式处理 Close 返回值时，可以把主体逻辑放在内部函数里，再由外层统一接住关闭错误：

func readTop(ctx context.Context, db *sql.DB, limit int) (items []string, err error) {
	rows, err := db.QueryContext(ctx, `SELECT name FROM people ORDER BY id`)
	if err != nil {
		return nil, err
	}

	// 用闭包集中处理读取错误，并让外层能够接住 Close 的返回值。
	func() {
		defer func() {
			if closeErr := rows.Close(); err == nil && closeErr != nil {
				err = closeErr
			}
		}()

		for rows.Next() && len(items) 

这不是所有项目都必须采用的模板。它适合“关闭错误有业务价值”的接口；普通读取函数若只需要保证资源释放，前一个简单版本更直观。接口设计的关键是先决定调用方需要看到哪些错误，再选择写法。

几个容易混淆的边界

最后的接口取舍

如果目标只是“查询前几条并返回”，我会采用“QueryContext 成功后立刻 defer Close，循环里处理 Scan，循环后检查 Rows.Err”的最小方案。它把调用方最容易忘记的动作固定下来，也不会因为一次 break 就留下模糊的资源边界。

如果接口还要区分关闭失败、多结果集或事务边界，再升级到显式接收 Close 错误的版本。无论选择哪种写法，核心判断不变：提前停止遍历不等于已经关闭 Rows。

相关问题：

• Rows 读完后还需要 Close 吗？ 建议仍然安排 Close，让资源责任对调用方明确，并覆盖未来新增的提前出口。
• 只检查 Rows.Err 能代替 Scan 错误吗？ 不能；Scan 处理当前行转换，Rows.Err 处理推进阶段错误。
• break 后直接 return 会不会自动归还连接？ 不应依赖隐式行为，拿到 Rows 后应明确安排 Close。