Golang中database/sql的QueryRow函数在单行数据查询中的资源泄露防范-Golang-PHP中文网

queryrow本身不导致连接泄漏，因其内部自动close；但误用scan错误处理、忽略null类型适配或依赖其校验唯一性，会引发逻辑错乱、panic或静默数据丢失。

golang中database/sql的queryrow函数在单行数据查询中的资源泄露防范

QueryRow 本身不会导致连接泄漏，但误用会掩盖问题

QueryRow 内部自动调用 rows.Close()，所以你不需要、也不能对它手动 Close()。这点和 db.Query() 完全不同——很多人混淆二者，以为“都得 close”，结果在 QueryRow 后加 defer rows.Close()，而 rows 实际是 *sql.Row 类型，没有 Close() 方法，编译不过或 panic。

真正危险的是：把 QueryRow 当成“更安全的 Query”，却在错误处理上偷懒，比如忽略 Scan() 的 err，或用 if err != nil 一刀切处理所有错误。这会导致两类泄漏隐患：

逻辑错乱后继续执行，可能触发后续无效查询，间接加重连接池压力
本该返回 sql.ErrNoRows 却被当成连接错误重试，反复建连又失败

Scan() 出错时必须显式判断 sql.ErrNoRows

QueryRow 不会在调用时返回错误，错误只出现在 Scan() 阶段。常见错误现象是程序直接 panic 或静默返回空值，比如字段类型不匹配（数据库 INT 扫到 *string）或 NULL 列用了非指针类型。

正确做法是：

始终检查 Scan() 返回的 err，而不是只看 QueryRow() 是否为 nil
用 errors.Is(err, sql.ErrNoRows) 区分“无数据”和“其他错误”
对非 ErrNoRows 的错误（如类型错、连接中断）要记录并终止流程，避免继续使用失效连接

示例：

var name string
err := db.QueryRow("SELECT name FROM users WHERE id = ?", 123).Scan(&name)
if err != nil {
    if errors.Is(err, sql.ErrNoRows) {
        // 业务逻辑：用户不存在
        return "", nil
    }
    // 其他错误：可能是连接断开、字段类型不匹配、权限不足等
    log.Printf("query user %d failed: %v", 123, err)
    return "", err
}