Go queryrow 出错时怎么查ErrNoRows

Go 里看到 sql: no rows in result set，通常不是数据库连接坏了，而是 QueryRow 没有找到符合条件的记录。这个判断有一个容易忽略的前提：QueryRow 调用本身只返回一个非空的 *sql.Row，真正读取结果并暴露错误的是后面的 Scan。

先确认 ErrNoRows 出现在哪一层

标准库把单行查询设计成“延迟取错”。因此下面的调用不会从 QueryRow 直接得到一个 error：

var email string
err := db.QueryRow("SELECT email FROM users WHERE id = ?", userID).Scan(&email)
// 先把查询结果扫描到目标变量，再根据 err 区分无数据和其他故障。
if err != nil {
    if errors.Is(err, sql.ErrNoRows) {
        // 没有匹配行是可预期的业务分支，不一定要打成数据库故障。
        return ErrUserNotFound
    }
    // 连接、SQL、驱动或类型转换问题继续向上返回。
    return fmt.Errorf("query user %d: %w", userID, err)
}
return email, nil

如果 SQL 没有返回行，Scan 才会给出 sql.ErrNoRows；如果 SQL 执行本身失败，同样会在 Scan 返回驱动或数据库错误。也就是说，排查时先看 err 的来源，再决定是否按“未找到”处理。

查询条件错了，最容易伪装成无数据

先不要急着把 ErrNoRows 改成重试。确认业务主键是否传对、占位符是否与参数顺序一致，以及查询是否带了额外的租户、状态或软删除条件。单行查询的检查可以压缩成这张表：

还要记住，QueryRow 只承诺读取第一行。若业务允许多条结果，就应该使用 Query 配合 Rows.Next，不要靠 QueryRow 把多行数据悄悄截断。

用 errors.Is 分出无数据、NULL 和转换错误

不要写 err.Error() == "sql: no rows in result set"。错误可能被上层包装，errors.Is 才能保留标准错误的身份判断：

var name string
var nickname sql.NullString
err := db.QueryRowContext(ctx,
    "SELECT name, nickname FROM users WHERE id = ?", userID,
).Scan(&name, &nickname)
// NullString 允许 nickname 为 NULL；它不会把 NULL 当成普通空字符串。
switch {
case errors.Is(err, sql.ErrNoRows):
    // 记录不存在：交给业务层决定返回 404、创建提示或空状态。
    return User{}, ErrUserNotFound
case err != nil:
    // 这里还可能是列数不匹配、类型转换失败或驱动错误。
    return User{}, fmt.Errorf("scan user: %w", err)
default:
    // Valid 为 false 时表示数据库列确实是 NULL。
    return User{Name: name, Nickname: nickname}, nil
}

这里的 sql.NullString 只是示例；日期、整数等可空列也应使用对应的 sql.NullTime、sql.NullInt64 等类型。若字段本来不允许 NULL，就应该回到表约束和数据写入路径排查，而不是无条件吞掉转换错误。

有超时要求时把上下文传进 QueryRowContext

QueryRow 内部使用 context.Background。请求处理、后台任务或批处理有取消边界时，应使用 QueryRowContext，并让调用方继续用 errors.Is 判断取消或超时：

ctx, cancel := context.WithTimeout(parent, 2*time.Second)
defer cancel() // 释放计时器资源，避免请求结束后继续保留定时器。

err := db.QueryRowContext(ctx,
    "SELECT email FROM users WHERE id = ?", userID,
).Scan(&email)
// 先识别没有记录，再识别上下文取消，最后保留其他错误的原因。
switch {
case errors.Is(err, sql.ErrNoRows):
    return ErrUserNotFound
case errors.Is(err, context.DeadlineExceeded), errors.Is(err, context.Canceled):
    return fmt.Errorf("load user canceled: %w", err)
case err != nil:
    return fmt.Errorf("load user: %w", err)
}

上下文超时不等于 ErrNoRows。如果日志只打印一条模糊的“查询为空”，后续很难分辨是主键传错还是请求已经被取消，所以建议在包装错误时保留原始错误。

常见问题

QueryRow 返回 nil 时才应该判断 ErrNoRows 吗？

不是。标准库的 QueryRow 返回非 nil 的 *sql.Row，应检查 Scan 返回的错误。

ErrNoRows 能说明 SQL 一定执行成功吗？

它说明本次单行读取没有得到匹配行；业务上仍应核对查询条件，但不能把它当成连接或语法错误。

想把没有记录当成默认值怎么办？

可以在 errors.Is(err, sql.ErrNoRows) 分支显式返回默认值，但要确认“缺失”和“字段为空”在业务上确实等价。

排查这类问题时，最有价值的顺序是：先确认 Scan 的原始错误，再核对 WHERE 参数，最后检查 NULL 与类型映射。这样能把真正的无数据分支和需要修复的数据库故障分开。