Go database/sql 如何处理 Rows.Close 错误：事务提交前的资源回收顺序

线上批量导入偶尔出现“事务已经提交，但结果不完整”的告警，排查时很容易只盯着 rows.Err()，却漏掉 Rows.Close 返回的错误。对 database/sql 来说，读取结束、关闭结果集和提交事务是三个不同的检查点；把它们揉成一个 defer，就可能在提交后才发现连接或驱动层的问题。

在事务内查询时，应先确认 rows.Err()，再显式处理 rows.Close()，两个检查都通过后才调用 Commit；任一点失败，都走 Rollback。

为什么 rows.Next 结束后还要检查两次

database/sql.Rows 把结果集读取封装成迭代器。Next 返回 false 可能表示没有下一行，也可能表示读取途中发生了错误；真正的读取结论要由 rows.Err() 给出。另一方面，Close 负责结束结果集，驱动可能在这里完成最后的网络读取或资源释放，因此它和 Err 不是同一个信号。

这也是为什么“循环结束就提交”不够稳：循环只说明迭代动作停了，不说明数据已经完整落地。

把关闭动作放到 Commit 之前

下面的示例以一个事务内的库存同步为背景。查询本身只读取 inventory_delta，真正的写入省略为注释，重点是四个真实节点：QueryContext、rows.Next、rows.Err、rows.Close。

func syncInventory(ctx context.Context, db *sql.DB) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }

    rows, err := tx.QueryContext(ctx, `
        SELECT sku, delta
        FROM inventory_delta
        WHERE batch_id = ?
        ORDER BY sku`, batchID)
    if err != nil {
        _ = tx.Rollback()
        return err
    }

    for rows.Next() {
        var sku string
        var delta int
        if err := rows.Scan(&sku, &delta); err != nil {
            _ = rows.Close()
            _ = tx.Rollback()
            return err
        }
        // 在事务内写入库存变更。
    }

    if err := rows.Err(); err != nil {
        _ = rows.Close()
        _ = tx.Rollback()
        return err
    }
    if err := rows.Close(); err != nil {
        _ = tx.Rollback()
        return err
    }
    return tx.Commit()
}

示例里没有使用无条件的 defer rows.Close() 来代替显式检查。实际项目可以再加一个兜底关闭，但兜底动作不应掩盖提交前的主检查。

Scan 出错时为什么先关 rows

Scan 失败时，当前结果集已经不能继续推进。先调用 rows.Close()，再回滚事务，可以尽早归还驱动资源。关闭本身若也失败，应把它写入日志或错误链，但不要因为记录关闭错误而跳过回滚。

读错、关错和提交错要分开记录

三类错误的责任边界不同：rows.Err() 更接近读取阶段，rows.Close() 更接近结果集收尾，Commit 则表示事务最终提交动作。日志至少应带上 batch_id，否则同一批数据的失败阶段很难区分。

一个实用的处理顺序是：

1. 查询创建失败：立即 Rollback，不创建后续读取流程。
2. Scan 或 rows.Err() 失败：停止读取，先关闭结果集，再回滚。
3. rows.Close() 失败：不提交，回滚并记录关闭阶段。
4. Commit 失败：记录提交错误，交给调用方决定重试或人工核对。

测试时要验收哪些可见结果

不要只断言函数返回 nil。正常路径应能看到提交后的库存变化；读取错误路径应确认写入没有对外可见；关闭错误路径则要确认没有继续调用 Commit。如果使用可注入的数据库驱动，分别让查询读取、结果集关闭和提交返回错误，三个分支都应有独立测试。

生产日志建议包含批次号、阶段名和事务结果，例如 rows_read、rows_close、commit。不要把数据库密码、完整 DSN 或用户输入拼进错误文本。

常见问题

rows.Next 返回 false 就代表没有错误吗？

不代表。它既可能表示正常读完，也可能表示读取错误；必须继续检查 rows.Err()。

已经 defer rows.Close 了，还要显式 Close 吗？

如果关闭错误会影响事务是否提交，就应在提交前显式调用并检查返回值；defer 可以作为异常退出时的兜底。

rows.Close 出错后能不能继续 Commit？

不建议。关闭失败说明结果集收尾未被确认，当前事务应回滚，并记录批次和关闭阶段。

小结

database/sql 的安全收尾不是“循环结束后直接提交”，而是把数据读取、结果集关闭和事务提交按顺序验收。只要把 rows.Err() 与 rows.Close() 放到 Commit 之前，失败就统一回滚，批量同步的异常边界会清楚很多。