Go sql.Rows 不生效怎么办

Go sql.Rows “不生效”通常需要按查询、迭代和扫描分别定位：先处理 QueryContext 的错误，再用 Next 定位当前行，随后检查 Scan 返回值，循环结束后还要检查 Err。Rows 不是已经填好的业务对象列表；忽略任一环节，都可能把错误误当成“没有数据”。

官方地址：https://pkg.go.dev/database/sql

先确定失败发生在哪个环节

假设一个库存查询接口返回空数组，不能直接归因为 Rows 有问题。SQL 条件可能没匹配，也可能 Scan 遇到 NULL，或者连接中途出错后代码仍返回了已收集的部分结果。这是原创排障场景，没有声称真实运行结果。

建议记录操作名称、成功扫描行数和错误阶段，避免记录连接密码、完整个人信息或敏感查询参数。先保留原始错误链，再决定是否重试，不能把任何错误都统一转为空列表。

完整消费一个结果集

package inventory

import (
    "context"
    "database/sql"
    "fmt"
)

type Item struct {
    ID int64
    Label sql.NullString
}

// ListItems 假设表包含非空整数 id 和可空文本 label，驱动支持问号占位符。
func ListItems(ctx context.Context, db *sql.DB, minID int64) (items []Item, err error) {
    rows, err := db.QueryContext(ctx,
        "SELECT id, label FROM inventory_item WHERE id >= ? ORDER BY id", minID)
    if err != nil {
        return nil, fmt.Errorf("query items: %w", err)
    }
    defer func() {
        // 提前返回也关闭结果集；已有错误优先保留。
        if closeErr := rows.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close items: %w", closeErr)
            items = nil
        }
    }()

    items = make([]Item, 0)
    for rows.Next() {
        var item Item
        if scanErr := rows.Scan(&item.ID, &item.Label); scanErr != nil {
            return nil, fmt.Errorf("scan item: %w", scanErr)
        }
        items = append(items, item) // 只收集已经成功扫描的记录。
    }
    if iterErr := rows.Err(); iterErr != nil {
        return nil, fmt.Errorf("iterate items: %w", iterErr)
    }
    return items, nil
}

这是依赖已有数据库与驱动的辅助函数，不是独立可运行程序。实际项目应使用自己表结构；PostgreSQL 等驱动可能要求其他占位符形式，不能直接照搬问号。保留明确列名也能避免 SELECT * 的列顺序变化让扫描目标错位。

Next 返回 false 既可能结束，也可能失败

不要先调用一次 Next 判断“是否有数据”，随后又进入 for rows.Next；前一次调用已经前移了位置，容易跳过首行。最小循环只保留一个推进点，并在循环后读 Err。

对多行查询，没有匹配记录通常表现为循环不进入且 Err 为 nil，不使用 QueryRow.Scan 的 ErrNoRows 作为统一判断。上例只在完整读取成功后返回结果；如果你的业务允许部分结果，应在返回结构中明确标识不完整，而不是悄悄吞掉错误。

NULL、目标类型与变量作用域

可空文本使用 sql.NullString，消费方应根据 Valid 区分 NULL 与空字符串。Scan 的目标数量要与列数一致，并使用可写目标。数据转换失败时，不能继续使用这一行的部分字段。

还要看业务结果是否被局部变量遮蔽。循环里用同名短声明创建另一份结果切片，函数外的变量不会因此自动得到数据。反过来，把一个可变指针在多次迭代中反复塞入列表，也需要明确各项是否真的独立。

提前停止后要关闭，但不要关闭共享 DB

业务找到目标就 break 时，defer rows.Close 仍然重要。不要把关闭推迟到永不结束的外层循环末尾。Rows.Close 释放结果集相关资源，但不是提交事务，也不等于关闭长期复用的 sql.DB。

在连接数很小的环境里，持有未关闭 Rows 又启动另一个依赖连接的操作，可能让后者等待连接。应先明确是否可以结束当前结果集，或调整业务查询方式，而不是简单无限增加连接数。请求上下文和超时也应覆盖结果消费过程。

相关问题

Rows 可以重新从第一行读取吗？没有通用的倒回接口，需要重新查询，或者明确保存已经消费的数据。

Close 能代替 Err 吗？不能。仍需检查迭代错误，扫描错误也在 Scan 调用处处理。

只要 QueryContext 成功就能放心返回吗？不能。结果消费时仍可能发生错误；应在函数完成前处理完整生命周期。

依据：Rows 官方文档、Go 数据查询指南。