QueryRow 查询返回空值时 panic 是因为未检查 sql.ErrNoRows 就解引用未初始化字段；必须用 errors.Is(err, sql.ErrNoRows) 显式处理，且 Scan 要求字段类型匹配、可寻址、非 nil 指针或 sql.Null 类型。
QueryRow 查询返回空值时为什么 panic？
Go 的 QueryRow 不会自动处理 SQL 查询结果为空的情况，它默认期望**恰好一行**数据。如果查不到，Scan 会返回 sql.ErrNoRows；如果查到多行，Scan 会只读第一行，但不会报错——这容易掩盖逻辑错误。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，往往是因为没检查 err 就直接解引用了未初始化的结构体字段。
- 必须显式检查
err是否为sql.ErrNoRows，不能只用if err != nil一并处理 - 不要在
Scan前对指针变量做非空判断（比如if user != nil），QueryRow.Scan本身不负责分配内存，它只往你传进去的地址里写值 - 推荐把
Scan和err检查写在同一层作用域，避免变量逃逸或提前声明导致误用
QueryRow 扫描 struct 字段失败的典型原因
QueryRow.Scan 要求目标字段类型与数据库列类型严格匹配，且字段必须是可寻址的导出字段（首字母大写）。它不支持嵌套 struct、map 或自定义类型自动转换（除非实现了 Scanner 接口）。
使用场景：查询用户单条记录并映射到 User 结构体。
立即学习“go语言免费学习笔记（深入）”；
- 字段名大小写必须和 SQL 列别名一致（推荐用
AS显式命名，如SELECT id, name AS Name FROM users） - 数据库中为 NULL 的列，对应 Go 字段类型必须是
*string、*int64等指针类型，或使用sql.NullString等包装类型 - 如果用了 ORM 风格的 tag（如
db:"name"），QueryRow.Scan完全不识别——那是第三方库（如 sqlx）的功能，原生database/sql只认字段名
如何安全地用 QueryRow 查询并处理可能的空结果
核心原则：把“无结果”当作正常业务路径，而不是异常分支。多数单行查询（如根据 ID 查用户）本就可能查不到，应主动建模这个状态。
var u User
err := db.QueryRow("SELECT id, name, email FROM users WHERE id = ?", userID).Scan(&u.ID, &u.Name, &u.Email)
if err != nil {
if errors.Is(err, sql.ErrNoRows) {
return nil, fmt.Errorf("user not found: %d", userID)
}
return nil, err
}
return &u, nil
- 不要用
if err == sql.ErrNoRows，Go 1.13+ 推荐用errors.Is(err, sql.ErrNoRows)，兼容包装错误 - 避免在
Scan后再做字段有效性校验（如u.ID == 0），因为sql.ErrNoRows已明确告诉你没数据，其他 err 才需要进一步排查 - 如果业务上允许“空对象”，可初始化一个零值 struct 并返回，但需确保调用方能区分“查到空记录”和“查不到”——后者更可能是 ID 不存在，前者可能是数据脏或状态异常
QueryRow 性能与连接复用需要注意什么
QueryRow 本身不阻塞，但它会从连接池取一个连接执行查询。如果并发量高且查询慢，可能耗尽连接池，导致后续请求卡在 QueryRow 调用上，而非 Scan。
- 务必设置
db.SetMaxOpenConns和db.SetMaxIdleConns，尤其在容器环境或云数据库下，默认值常偏低 -
QueryRow返回的*Row对象不需要手动 Close——它内部会自动归还连接；但若你忘了调用Scan，连接会一直占用直到超时 - 不要在循环里反复调用
QueryRow查询多条数据，应改用Query+rows.Next，否则每轮都抢连接，性能断崖式下降
最常被忽略的是：QueryRow 的上下文控制。生产代码必须传入带超时的 context.Context，否则一个慢查询可能拖垮整个服务。用 db.QueryRowContext(ctx, ...) 替代裸调用。
