Go rows.Close 调用后 Err 还能不能发现驱动错误

会。rows.Close() 之后仍然可以调用 rows.Err()，而且显式关闭不会把已经记录的迭代错误清掉。真正容易漏掉的是：Err()主要回答“遍历结果集时有没有错”，Close()则可能直接返回底层驱动在关闭游标时报告的错误。只写 defer rows.Close()，再完全忽略 Close 返回值，遇到提前结束或写入型语句时就可能丢失信息。

Close 和 Err 其实在回答两个问题

Rows.Close 的职责是停止继续枚举并释放结果集资源。官方文档明确说，Next 返回 false 且没有更多结果集时，Rows 通常已经自动关闭，此时检查 Rows.Err 就足够；Close 本身是幂等的，调用它不会影响 Err 的结果。

Rows.Err 的职责是报告遍历期间遇到的错误。因为 Next 返回 false 既可能是“没有下一行”，也可能是驱动取下一行时失败，所以不能把 false 当成成功结束的证据。调用关系可以先这样理解：

读取型查询的稳妥写法是 Err 加 Close 双保险

普通只读查询可以让循环自然走到结束，再检查 rows.Err()。下面的写法还把显式关闭错误接到命名返回值上：只有前面没有更具体的错误时，关闭失败才会成为最终错误，避免覆盖扫描或迭代阶段的根因。

func loadUsers(ctx context.Context, db *sql.DB) (_ []User, err error) {
    // QueryContext 的错误表示查询尚未拿到可用结果集。
    rows, err := db.QueryContext(ctx, "SELECT id, name FROM users")
    if err != nil {
        return nil, fmt.Errorf("query users: %w", err)
    }
    // 兜底释放结果集；若前面没有错误，再保留 Close 的失败原因。
    defer func() {
        if closeErr := rows.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close rows: %w", closeErr)
        }
    }()

    users := make([]User, 0)
    for rows.Next() {
        var user User
        // Scan 错误属于当前行的转换或目标参数问题，不由 Rows.Err 替代。
        if scanErr := rows.Scan(&user.ID, &user.Name); scanErr != nil {
            return nil, fmt.Errorf("scan user: %w", scanErr)
        }
        users = append(users, user)
    }
    // Next 返回 false 后，用 Err 区分正常结束与驱动迭代失败。
    if iterErr := rows.Err(); iterErr != nil {
        return nil, fmt.Errorf("iterate users: %w", iterErr)
    }
    return users, nil
}

这里的 defer 不是用来替代 Err 的。循环后仍要读 Err，因为驱动在最后一次 Next 时才暴露的错误，往往只能从那里得到。反过来，Close 的返回值也有自己的意义：如果底层驱动在关闭游标时失败，直接检查它能让错误日志更准确。

提前结束时不要把 Close 当成无返回值函数

分页、只取前几行或扫描失败后，调用方可能还没有让 Next 自然走到 EOF。这时应该显式关闭，并保留两个来源的错误。若是只读查询，通常按“已有业务错误优先，Close 错误补充”处理；若一个批次同时读写，Close 阶段的错误可能代表驱动正在回滚或提交失败，更不能静默丢弃。

func firstUser(ctx context.Context, db *sql.DB) (user User, err error) {
    // 这个查询只消费一行，所以不会自然遍历到结果集末尾。
    rows, err := db.QueryContext(ctx, "SELECT id, name FROM users ORDER BY id")
    if err != nil {
        return user, err
    }
    if !rows.Next() {
        // 即使没有行，也要读取迭代阶段的上下文或驱动错误。
        if iterErr := rows.Err(); iterErr != nil {
            _ = rows.Close()
            return user, iterErr
        }
        return user, rows.Close()
    }
    // 当前行扫描失败时，先保留 Scan 的根因，再释放结果集。
    if err = rows.Scan(&user.ID, &user.Name); err != nil {
        _ = rows.Close()
        return user, err
    }
    // 提前结束枚举，Close 的返回值仍需进入错误处理。
    if closeErr := rows.Close(); closeErr != nil {
        return user, fmt.Errorf("close after first row: %w", closeErr)
    }
    return user, nil
}

用这张检查表判断线上症状

• 循环少拿了几行，Next 变成 false：先看 rows.Err()，不要只看已返回的行数。
• Scan 直接报错：保留 Scan 错误，检查列顺序、NULL 值和目标类型；它不是靠再次调用 Err 修复的。
• context 已取消：让查询使用同一个上下文，并在循环结束后检查 Err，确认取消是否就是失败原因。
• Close 返回非 nil：记录 Close 错误；如果前面已有更具体的业务错误，使用错误包装或日志字段同时保留两者。

相关问题

rows.Close 调用两次会报错吗？

标准库的 Rows.Close 是幂等的，重复调用不会因为“已经关闭”自动变成新的业务错误，但第二次调用也不能替代第一次对返回值的处理。

循环结束后只写 rows.Close 可以吗？

不建议。Close 负责资源生命周期，Err 负责报告迭代错误；两者语义不同，完整读取后至少检查一次 rows.Err。

rows.Err 能发现 Scan 类型转换错误吗？

不能把它当作 Scan 的替代品。Scan 返回值应在当前行立即处理，Err 主要用于 Next 或结果集迭代阶段的错误。

什么时候可以只依赖 rows.Err？

当 Next 已经返回 false、没有更多结果集，且代码没有需要单独确认的提前 Close 失败时，循环后的 rows.Err 是标准的结束检查。