QueryRow本身不导致连接泄漏，因其内部自动Close；但误用Scan错误处理、忽略NULL类型适配或依赖其校验唯一性，会引发逻辑错乱、panic或静默数据丢失。
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 列用了非指针类型。
正确做法是：
立即学习“go语言免费学习笔记（深入）”；
- 始终检查
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
}
NULL 列没用指针或 sql.Null* 类型会 panic
数据库字段允许为 NULL，但 Go 的 Scan() 不会自动转成零值——它要么填成功，要么 panic。比如列定义为 name VARCHAR(255) NULL，却用 var name string 和 &name 接收，遇到 NULL 就直接崩溃。
解决方式只有两种，且必须显式选择：
- 用指针类型：
var name *string，Scan()后检查name == nil - 用
sql.NullString等包装类型：var name sql.NullString，再判断name.Valid
别试图“先查 schema 再决定怎么扫”——开销大、不可靠，且绕不开类型声明。只要表结构里某列允许 NULL，Go 侧就必须用可空类型接收。
QueryRow 返回多行时只取第一行，其余静默丢弃
这是最易被忽略的语义陷阱：QueryRow 从不报错，哪怕 SQL 实际返回 100 行，它也只扫第一行，剩下 99 行被底层连接悄悄丢掉。这在唯一性约束失效（比如索引漏建、业务逻辑重复插入）时，会让 bug 难以暴露。
如果你的业务要求「必须且仅有一行」，不能只依赖 QueryRow，而应：
- 在数据库层加
UNIQUE约束或主键保证 - 必要时改用
db.Query()+rows.Next()，并在第二次Next()返回true时主动报错 - 日志中记录“预期单行但收到多行”的异常事件，用于监控
别把 QueryRow 当作校验工具——它只是取第一行的快捷方式，不是一致性断言。
