事务 Commit 失败时为什么不能简单忽略回滚

我在整理一段 Go 写库代码时，最容易被忽略的不是 ExecContext，而是最后那句 Commit。如果提交返回错误，不能把它当成“回滚一下就好”，更不能继续使用事务里的查询结果或把更新结果返回给调用方。Go 官方文档的边界很明确：只有 Commit 成功，事务内的结果才可以确认；提交失败时，事务内的查询和执行结果都应丢弃。

官方资料：https://go.dev/doc/database/execute-transactions

实用的收尾规则是：事务创建成功后立刻登记 defer tx.Rollback()，所有 SQL 错误直接返回；最后单独判断 Commit 错误。这个回滚是兜底路径，不是把提交失败改成成功的修复按钮。

先看 Commit 失败改变了什么

sql.Tx 代表一段进行中的事务。前面的 ExecContext 或 QueryRowContext 只是把操作放进事务语境，并不等于调用方已经拿到了最终确认结果。最终确认点是 Commit。

所以这种写法有问题：

if err := tx.Commit(); err != nil {
    // 错误不能被吞掉；Commit 失败时事务结果不能当作已提交。
    return orderID, nil
}

它把“提交失败”和“业务成功”拼在了一起。更危险的是，调用方可能据此发送成功通知、写入下游消息，或者把同一笔写操作再次无条件重放，造成业务状态与数据库状态无法判断。

把 Rollback 放进兜底路径

事务创建成功后尽快登记回滚，是为了覆盖中途的每一种返回路径。若后续 SQL 出错，函数提前返回时由 defer 尝试回滚；若所有操作成功，代码继续执行 Commit，之后延迟回滚通常只会面对一个已经结束的事务。这里不需要把延迟回滚的错误重新改写成主错误。

func createOrder(ctx context.Context, db *sql.DB, userID int64) (int64, error) {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return 0, err
    }
    // 事务创建成功后立即登记兜底回滚，覆盖中途返回和提交失败路径。
    defer tx.Rollback()

    var orderID int64
    if err := tx.QueryRowContext(ctx,
        `INSERT INTO orders (user_id) VALUES (?) RETURNING id`, userID,
    ).Scan(&orderID); err != nil {
        // SQL 失败直接返回；defer 会尝试结束未完成事务。
        return 0, fmt.Errorf("insert order: %w", err)
    }

    if _, err := tx.ExecContext(ctx,
        `INSERT INTO order_events (order_id, event) VALUES (?, ?)`, orderID, "created",
    ); err != nil {
        // 第二个写操作失败时，不应继续提交第一步的结果。
        return 0, fmt.Errorf("insert order event: %w", err)
    }

    if err := tx.Commit(); err != nil {
        // Commit 非 nil 时，事务内结果全部作废并向上报告。
        return 0, fmt.Errorf("commit transaction: %w", err)
    }
    // 只有 Commit 成功，才把订单号作为已确认结果返回。
    return orderID, nil
}

这个函数的关键不是“每次都一定能回滚成功”，而是让主错误不被延迟清理覆盖：SQL 错误和提交错误都返回给调用方，回滚只承担兜底收尾职责。若回滚本身失败，仍然不能把函数改成成功；应通过日志、指标或上层错误链记录它。

区分事务连接与普通 DB 调用

sql.DB 是连接池句柄，sql.Tx 则绑定到一条事务连接。事务中的 SQL 应使用 tx.ExecContext、tx.QueryContext 等方法；如果中途改用 db.ExecContext，那条操作可能在事务外执行，读到或写出与事务不一致的状态。

官方资料：https://pkg.go.dev/database/sql

事务结束后，提交或回滚都会让事务连接回到连接池。因而“忽略错误”不只是少打一条日志：它会让业务层在事务已经结束后继续使用一个不再代表有效事务的结果，并掩盖连接生命周期已经发生变化这一事实。

决定提交失败后的业务动作

提交失败后是否重试，不能只看“有错误”三个字。先把问题拆成两个层次：

1. 数据库层：保留原始错误，确认事务结果不能继续当作成功；不要在没有幂等保护时无条件重放写操作。
2. 业务层：如果这笔操作允许重试，使用业务幂等键、唯一约束或补偿记录，让重复请求落到同一业务结果；如果不能安全判断，就进入人工或异步补偿流程。

这里的“回滚”只处理当前事务的收尾，不负责撤销已经发出的站外副作用。例如付款通知、消息投递、文件写入等动作不应和一次数据库回滚混为同一件事；它们需要幂等消费、事务消息或补偿表等独立设计。

用一个最小函数收口责任

可以把检查清单压缩成四句话：开始事务后立刻登记回滚；事务内只用 tx 执行 SQL；Commit 错误必须返回；只有提交成功才向调用方暴露成功结果。这样，调用方看到的返回值和数据库事务确认点是一致的。

常见追问

Commit 失败后还需要手动 Rollback 吗？

建议保留 defer tx.Rollback() 作为统一兜底路径，但不要把它当成把提交失败变成成功的动作。事务一旦结束，回滚可能只返回事务已完成之类的错误。

为什么不能只判断最后一个 Exec 的错误？

因为前面的写操作是否最终生效，要等 Commit 成功确认；最后一个 Exec 成功不等于整个事务已经提交。

提交失败时能不能直接重试整个事务？

只有在数据库驱动语义、业务幂等约束和外部副作用都允许时才考虑重试。默认做法是保留原始错误并进入明确的补偿或人工处理路径。