Go sqlmock 怎么检查查询结果集是否被关闭

在 sqlmock 的 ExpectQuery 期望上添加 RowsWillBeClosed()，并在被测函数返回后调用 ExpectationsWereMet()，就能检查该查询返回的结果集是否已关闭。它检查的是关闭状态，不是源码里有没有写 defer；因此测试样本还需要覆盖未读完就返回的路径。

官方地址：https://github.com/DATA-DOG/go-sqlmock

遇到结果集未关闭提示，先锁定查询边界

设想一个查询名称的函数只需要第一条记录，拿到值就返回。SQL 和参数都匹配，返回值也正确，但结果集仍可能保持打开。不能用“业务断言通过”代替资源释放检查。

这篇只处理 QueryContext 返回的 Rows。sqlmock 是模拟 SQL 驱动的测试工具，不需要真实数据库，也不能据此证明生产连接池不存在泄漏。下面用固定两行数据表达提前返回场景，示例未在本文制作过程中本地执行。

区分结果集关闭和数据库关闭

RowsWillBeClosed 属于查询期望，针对查询结果集；ExpectClose 针对数据库句柄的 Close，二者不是同一个资源。修复时应先找清楚谁拥有 Rows：函数内部消费就由函数关闭；若函数把 Rows 返回给调用者，关闭责任随接口转移。

还要注意完整遍历的情况：当 Next 返回 false 且没有后续结果集时，database/sql 会自动关闭 Rows。因此，一个读到末尾的用例即使没有显式 defer，也可能满足关闭期望。它不能独自覆盖提前返回的风险。相关规则见 Rows.Close 文档。

给提前返回路径加上最小测试

在独立示例目录使用下列命令准备依赖。固定 v1.5.2 只是本文的依赖基准，不表示它是最新发布版本。

# 初始化一个只用于演示结果集关闭的模块。
go mod init example.com/rows-close-demo
# 固定 sqlmock 依赖，便于复现同一测试配置。
go get github.com/DATA-DOG/go-sqlmock@v1.5.2

保存下面完整内容为 rows_test.go。业务函数只读取第一行，第二行不会被消费。QueryMatcherEqual 明确使用字符串匹配，避免默认正则匹配给这个资源测试增加无关变量。

package rowsdemo

import (
    "context"
    "database/sql"
    "testing"

    "github.com/DATA-DOG/go-sqlmock"
)

const lookupSQL = "SELECT name FROM accounts WHERE active = ?"

func firstActiveName(ctx context.Context, db *sql.DB) (string, error) {
    rows, err := db.QueryContext(ctx, lookupSQL, true)
    if err != nil {
        return "", err
    }
    // 查询成功后立即登记释放责任，覆盖提前返回和 Scan 失败。
    defer rows.Close()

    if !rows.Next() {
        if err := rows.Err(); err != nil {
            return "", err
        }
        return "", sql.ErrNoRows
    }

    var name string
    if err := rows.Scan(&name); err != nil {
        return "", err
    }
    return name, nil
}

func TestFirstActiveNameClosesRows(t *testing.T) {
    db, mock, err := sqlmock.New(
        sqlmock.QueryMatcherOption(sqlmock.QueryMatcherEqual),
    )
    if err != nil {
        t.Fatal(err)
    }
    // 数据库测试句柄的清理不能代替查询结果集的关闭检查。
    defer db.Close()

    result := sqlmock.NewRows([]string{"name"}).
        AddRow("north").
        AddRow("south")
    mock.ExpectQuery(lookupSQL).
        WithArgs(true).
        WillReturnRows(result).
        RowsWillBeClosed()

    got, callErr := firstActiveName(context.Background(), db)
    if callErr != nil {
        t.Errorf("query failed: %v", callErr)
    }
    if got != "north" {
        t.Errorf("name = %q, want north", got)
    }
    // 必须在业务函数返回之后、数据库清理之前检查期望。
    if err := mock.ExpectationsWereMet(); err != nil {
        t.Errorf("mock expectations: %v", err)
    }
}

测试没有读取第二行，也没有再调用 Next 到末尾。这样，正常返回是否释放结果集就成为用例的核心，而不依赖完整遍历带来的自动关闭。函数里的 defer 在函数返回时执行，之后再检查 mock 期望。

修复不生效时，回退无关改动而不是删期望

若增加关闭检查后出现失败，先保持 SQL、参数和返回样本不变，只处理释放责任。查询成功后再登记 defer；不能在 QueryContext 报错时对可能为空的 Rows 调用 Close。

不要把关闭责任挪到一个长期运行的大循环外层，然后以为每次迭代都释放。需要每次查询及时关闭时，优先把一次查询的处理封装成独立函数。对于本例，只需保持 defer 在 firstActiveName 的函数作用域。

回退策略是撤销无关 SQL 改写、参数匹配变更或返回值重构，保留同一条 RowsWillBeClosed 断言。删掉断言只能让测试不再检查资源责任，并不能修复业务代码。若原接口承诺把 Rows 交给调用方，不要擅自提前关闭，而应把检查放到真正消费结果集的调用链测试。

用失败对照确认断言检查了什么

读者可运行下列命令定位这个测试：

# 只执行当前资源释放用例，并禁用测试结果缓存。
go test -run '^TestFirstActiveNameClosesRows$' -count=1 .

按上述代码和规则，预期用例通过。作为临时反例，移除业务函数的 defer rows.Close 后再次运行：预期业务值仍可能正确，而 ExpectationsWereMet 返回未关闭结果集的错误。对照后恢复 defer，不要把故意漏关的代码提交到业务分支。这里描述的是可复现的预期，不是实测日志。

把资源责任写进后续测试清单

复盘时记录四件事：是哪条查询创建 Rows、哪个函数消费它、什么分支提前返回、期望检查位于什么位置。测试应在实际消费函数结束后检查状态，而不是提前检查，或者等数据库整体清理后才检查。

只加 RowsWillBeClosed 就够了吗？不够，还要调用 ExpectationsWereMet，否则没有汇总这项期望是否满足。

测试通过能证明显式 Close 被调用吗？不能。完整遍历也可能触发自动关闭，所以本例刻意保留未读数据。

需要真的连数据库吗？这个单元测试不需要。驱动行为、连接池和生产负载仍属于另外的集成与运行观察范围。

接口参考：RowsWillBeClosed 官方文档。将关闭状态检查与业务值断言分开，才容易定位“数据正确但资源责任遗漏”的问题。