Go database/sql事务提交后 Rows 仍未关闭怎么办

如果 Go 的 database/sql 事务已经调用了 Commit，但你仍然观察到 Rows 没有及时关闭，先不要把问题归结为“提交失效”。更常见的原因是结果集提前退出、没有显式调用 Rows.Close，或者把事务结束和结果集错误混在了一起。修复原则是：查询成功后立刻登记关闭责任，遍历结束检查 Rows.Err，需要提前提交时先显式关闭，再提交事务。

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

正常读完所有结果时，Next 到达末尾会触发自动关闭；但业务代码不应该依赖“刚好读完”。只要存在提前返回、只取前几行、扫描失败或多结果集，提交前显式关闭 Rows 才能让生命周期清晰。

先区分事务结束和 Rows 结束

Tx.Commit 负责提交事务，Rows.Close 负责结束当前结果集并释放它持有的资源。两者有关联，但不是同一个动作。事务查询通常占用事务连接；如果结果集还在流式读取，提交过程可能需要先等待或协调查询结束。即使当前驱动最终能把它收尾，也不代表代码可以忽略 Close。

另外，Rows.Close 是幂等的，已经自动关闭后再次调用通常没有副作用。因此“显式关闭”不是重复释放，而是把提前退出和错误路径也纳入同一条规则。

最小修复：提交前结束结果集

下面的例子先读取需要的行，再关闭结果集，最后执行写操作并提交。示例使用 ? 作为占位符，实际语法应以所用驱动为准。

func settleOrder(ctx context.Context, db *sql.DB, orderID int64) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer func() {
        // 提交成功后 Rollback 只会返回事务已结束，作为兜底即可。
        _ = tx.Rollback()
    }()

    rows, err := tx.QueryContext(ctx,
        "SELECT item_id, quantity FROM order_items WHERE order_id = ?", orderID)
    if err != nil {
        return err
    }

    var total int64
    for rows.Next() {
        var itemID, quantity int64
        // Scan 失败时立即退出，后面的 Close 仍必须执行。
        if err := rows.Scan(&itemID, &quantity); err != nil {
            _ = rows.Close()
            return err
        }
        total += quantity
    }
    // Next 返回 false 既可能是读完，也可能是驱动报错。
    if err := rows.Err(); err != nil {
        _ = rows.Close()
        return err
    }
    if err := rows.Close(); err != nil {
        return err
    }

    // 结果集已结束，再做同一事务中的写操作。
    if _, err := tx.ExecContext(ctx,
        "UPDATE orders SET item_count = ? WHERE id = ?", total, orderID); err != nil {
        return err
    }
    // Commit 成功后，defer 中的 Rollback 不会撤销已提交的数据。
    return tx.Commit()
}

为什么 defer rows.Close 仍然值得保留

如果函数只有完整遍历这一条路径，for rows.Next() 读到末尾时通常会自动关闭。但中途的 Scan 错误、业务筛选后的提前返回、上下文取消，都可能让循环没有走到末尾。更稳妥的写法是在拿到 Rows 后立刻写 defer rows.Close()，并在必须提交前再显式调用一次；关闭是幂等的。

这里有一个时序取舍：如果函数要在读取后马上 Commit，不要只把关闭放在函数末尾的 defer 中，因为 defer 会晚于 Commit 执行。可以把读取逻辑拆成小函数，让小函数返回前关闭，或者像上例一样在提交前明确调用。

排查“仍未关闭”的四个证据

1. 是否提前退出。 搜索循环内的 return、break 和错误分支；只取一行也要关闭。
2. 是否检查了 Rows.Err。 Next 返回 false 不等于成功读完，网络中断或驱动错误要从 Err 读取。
3. 是否把同一事务连接当成普通 DB 使用。 事务中的查询、关闭和提交应保持同一条生命周期，不能把 Rows 交给另一个 goroutine 随意读取。
4. 连接池是否真的在等待。 在低 MaxOpenConns 的测试环境中并发执行两次查询；如果第二次长期等待，优先检查 Rows、Stmt 和 Tx 的释放路径，而不是盲目增加连接数。

提交、回滚和 Close 的边界

提交前的 Rows.Close 返回错误时，应该把它当成当前事务无法安全收尾的信号，交给兜底 Rollback，不要继续提交。提交本身失败也不能再假设数据已经落库，调用方应记录错误并按业务幂等策略处理。Tx 在 Commit 或 Rollback 后不能继续执行事务操作；如果上下文被取消，事务也可能被回滚。

最终检查可以压缩成一张清单：QueryContext 成功后登记关闭；每次 Scan 失败都能退出；循环后检查 Rows.Err；提交前显式 Rows.Close；所有失败路径都有 Rollback 兜底。这样即使驱动的内部收尾策略不同，业务代码仍然拥有确定的资源边界。

相关问题

读完 Rows 后还需要 Close 吗？

建议保留。读到末尾通常会自动关闭，但显式调用能覆盖提前返回和未来的代码改动，而且调用是幂等的。

Rows.Close 返回错误要不要忽略？

在只读查询里可以按业务需要记录；在事务提交前不建议忽略，应先结束事务并返回错误，避免把结果集收尾失败隐藏起来。