Go sql.Tx 如何让回滚在提交后不覆盖结果

Go 的 database/sql 事务通常有一个看似矛盾的写法：事务成功时调用 Commit，函数前面却又注册了 defer tx.Rollback()。这两者并不冲突。Rollback 是提前返回时的清理兜底；当 Commit 已经成功，事务就不再处于可回滚状态，延迟调用不会把已提交的数据撤回。

defer Rollback 为什么不会覆盖已经提交的事务

Go 官方事务示例采用的就是“先注册回滚、最后提交”的结构。defer 会在当前函数返回前执行，所以中间任一条 SQL 出错，或者业务校验不通过，回滚都能兜底；如果函数走到最后并且 Commit 成功，后面的 Rollback 只会面对一个已经结束的事务，不会再次改变数据库状态。

这里的关键不是把回滚错误吞掉，而是明确它的职责：回滚负责清理未提交的事务，提交负责确认结果。不要在延迟函数里覆盖命名返回值，否则真正的 SQL 错误可能被一次清理调用遮住。

一套可复用的事务收尾写法

把回滚注册在事务创建成功之后，能覆盖后续所有提前返回路径。示例中的 SQL 仅用于说明事务边界，驱动、占位符写法和具体表结构应以实际数据库为准。

func transfer(ctx context.Context, db *sql.DB, fromID, toID int64, amount int64) error {
    // BeginTx 成功后，后续的查询和更新都应使用同一个 tx。
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("开始事务失败: %w", err)
    }
    // 提前返回时回滚；Commit 成功后这次调用不会撤销已提交结果。
    defer tx.Rollback()

    // 使用 tx.ExecContext，避免把写操作放到事务外的 db 连接。
    if _, err = tx.ExecContext(ctx,
        "UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?",
        amount, fromID, amount,
    ); err != nil {
        return fmt.Errorf("扣款失败: %w", err)
    }

    // 入账仍属于同一个事务，业务校验失败时直接返回并触发回滚。
    if _, err = tx.ExecContext(ctx,
        "UPDATE accounts SET balance = balance + ? WHERE id = ?",
        amount, toID,
    ); err != nil {
        return fmt.Errorf("入账失败: %w", err)
    }

    // Commit 的错误必须交给调用方，不能用此前的 SQL 结果推断提交成功。
    if err = tx.Commit(); err != nil {
        return fmt.Errorf("提交事务失败: %w", err)
    }
    return nil
}

这段代码有三个容易漏掉的检查点：第一，BeginTx 失败时没有可回滚对象；第二，所有事务 SQL 都挂在 tx 上；第三，Commit 放在最后，并且它的错误不会被忽略。成功路径只返回 nil，表示调用方可以把这次变更当作已确认结果。

Commit 出错时为什么不能继续使用事务结果

SQL 执行成功不等于事务已经提交。ExecContext 或 QueryContext 只说明事务内操作返回了结果，最终是否成为数据库的原子变更，要看 Commit。官方文档明确要求：如果提交失败，事务内查询和更新得到的结果都应丢弃。

因此，调用方应该把提交错误当作一次未确定的业务结果处理。例如转账接口不能因为两条 UPDATE 都没有报错，就直接返回“转账成功”；必须先收到 Commit 的 nil。如果业务允许重试，还要结合订单号、幂等键或数据库状态查询设计重试策略，不能盲目重复扣款。

最容易把事务写坏的三个细节

一是开始事务后又调用 db.Exec：这个调用不属于当前 sql.Tx，可能造成一半写入已经生效、另一半仍在事务中。二是把 defer tx.Rollback() 写成会覆盖命名返回错误的复杂闭包，清理失败不应盖住原始业务错误。三是忽略 Commit 的返回值；提交失败时，前面拿到的数据不能继续作为成功依据。

还要注意上下文取消。使用 BeginTx、ExecContext 和 QueryContext 可以让事务操作响应请求超时或取消，但是否能够安全重试，仍取决于业务的幂等设计。

相关问题

defer tx.Rollback() 的错误需要记录吗？

多数业务函数把它当作清理兜底并忽略返回值即可，尤其是成功提交后它本来就是无操作。若回滚失败本身会影响告警或连接健康，可以在专门的日志或指标中记录，但不要覆盖原始业务错误。

Commit 返回错误后还能再 Rollback 吗？

可以让已经注册的延迟回滚继续执行，但不能据此推断提交一定成功或一定失败。调用方应保留 Commit 错误，把事务内结果视为无效，并按业务幂等策略查询或处理后续动作。

事务里能同时使用 db.Query 和 tx.Query 吗？

不建议。事务相关查询应使用 tx 方法，否则查询可能落在事务外连接上，读到不一致状态，甚至在并发场景产生难以定位的锁问题。