Go database/sql Rows 关闭后继续 Next 会怎样

Go 的 database/sql.Rows 已经 Close 后，再调用 Next 会返回 false，不会重新执行查询或恢复游标。尤其要注意：主动关闭本身不一定让 Err 返回非 nil，所以“Next 为 false 且 Err 为 nil”不能单独证明查询原本没有数据。

官方文档：https://pkg.go.dev/database/sql#Rows.Close。Close 终止继续枚举，Err 则用于查询迭代错误，两者不是同一个状态判断接口。

查询成功却没有进入循环

假设一个列表接口把查询抽成辅助函数：QueryContext 没报错，调用方拿到 Rows 后却一次也没进入 for 循环。这个场景用于分析，不是已经发生的线上故障；本文也没有连接数据库执行样例。

对我来说，这种“看起来没有数据”的现象，首先值得检查资源的所有权。查询成功只能说明获得结果对象，不能保证这个对象在调用方开始读取时仍然打开。我不会仅凭空切片就先改 SQL 或怀疑驱动丢行。

把关闭位置放回调用链

下面的辅助函数虽然返回 Rows，但 defer 会在函数退出时执行。于是调用方拿到的对象已经关闭：

// 错误示意片段：返回对象，却把关闭责任留在本函数。
func queryRows(ctx context.Context, db *sql.DB, query string) (*sql.Rows, error) {
    rows, err := db.QueryContext(ctx, query)
    if err != nil {
        return nil, err
    }
    defer rows.Close() // 函数返回前关闭，不会等调用方读完。
    return rows, nil
}

这里的触发条件是“辅助函数不消费结果，却执行关闭”。按这个调用关系推导，Next 不再准备后续行。修复方向不是删掉所有 Close，而是把关闭责任放到真正消费结果的层：要么辅助函数直接返回普通数据，要么明确把仍然打开的 Rows 交给调用方。

false 与 Err 的含义不能混用

Next 的 false 有几种可能：当前结果集没有下一行、准备下一行时出错，或者 Rows 已关闭。正常遍历应在循环结束后检查 Err；但提前主动关闭会让剩余数据停止枚举，Err 为 nil 也不能补出未读取部分的证明。

当前官方实现会检查内部 closed 状态，在该状态下直接返回 false，而不再次向驱动请求下一行。源码参考：https://go.dev/src/database/sql/sql.go。不要期待这个动作必然产生一个“Rows 已关闭”的迭代错误；Scan、Columns 等方法的错误语义不能套到 Next 上。

当 Next 返回 false 且没有后续结果集时，Rows 会自动关闭。多结果集是一个额外边界：当前集结束不必然等于全部集结束，不能一概说所有 false 都自动完成全部资源收尾。

让消费函数拥有关闭责任

下面采用“查询并读出普通数据”的写法。输入的 query 应由应用控制并返回一列可扫描为 int64 的值；args 使用驱动支持的参数占位方式，不能拼接不可信 SQL。使用 Go 1.20 或更新版本，以便组合关闭错误。

package example

import (
    "context"
    "database/sql"
    "errors"
    "fmt"
)

// 返回普通数据，不把 Rows 跨越函数边界交给未知消费者。
func ReadIDs(ctx context.Context, db *sql.DB, query string, args ...any) (ids []int64, err error) {
    rows, err := db.QueryContext(ctx, query, args...)
    if err != nil {
        return nil, fmt.Errorf("发起查询: %w", err)
    }
    defer func() {
        // 提前返回也释放 Rows；保留关闭阶段错误，不覆盖主错误。
        if closeErr := rows.Close(); closeErr != nil {
            err = errors.Join(err, fmt.Errorf("关闭结果: %w", closeErr))
        }
    }()

    for rows.Next() {
        var id int64
        // 只有 Next 成功准备当前行，才读取其字段。
        if scanErr := rows.Scan(&id); scanErr != nil {
            return nil, fmt.Errorf("读取字段: %w", scanErr)
        }
        ids = append(ids, id)
    }
    if iterErr := rows.Err(); iterErr != nil {
        // 不把迭代中断前得到的部分数据当作完整成功。
        return nil, fmt.Errorf("迭代结果: %w", iterErr)
    }
    return ids, nil
}

这是接入现有数据库连接的函数，不是无驱动即可运行的完整程序，也没有硬编码账号或连接串。它的范围是单个结果集；若业务需要多结果集，应另行明确枚举规则。

这个取舍对我来说更清晰：调用方只获得普通切片，不需要猜谁会关闭结果；代价是把选定结果集读入内存，不适合无边界的大查询。流式接口仍可以返回 Rows，但必须把关闭责任明确交给消费者，并避免返回后在生产者一侧关闭或继续读取。

防止把关闭当成读完的证明

反向看这个假设问题，如果把辅助函数改成在内部完成读取，或者把关闭责任交给调用方，“返回前关闭”这个触发条件便被移除。但具体查询是否有数据仍需由自己的数据库用例判断，不能据此保证一定读到某个行数。

我会在接口说明里区分三件事：结果由谁消费、提前停止是不是业务允许、迭代错误怎样传回。若提前 break，应当承认只消费了部分结果并及时关闭，不能再把 Err=nil 解释为全部结果读取成功。通用查询用法参考：https://go.dev/doc/database/querying。

Rows.Close 可以调用两次吗？

Close 是幂等操作，重复调用不会重新开启结果。惯常 defer 作为退出收尾，并不改变循环正常结束后自动关闭的行为。

关闭后可以查询 Err 吗？

可以，显式或隐式 Close 后均可调用 Err。它报告迭代错误，不是一个“是否读完全部数据”的独立证明。

关闭 Rows 会关闭整个 DB 吗？

不会。Rows 是这次结果的资源对象，DB 是应用的连接池句柄。不要为了结束一次结果读取，在短生命周期辅助函数中关闭共享 DB。