当前位置：首页 > 文章列表 > Golang > Go问答 > 事务 Commit 失败时为什么不能简单忽略回滚

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

来源：17golang原创 2026-11-13 10:56:25 0浏览收藏

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

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

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

Go database/sql 事务操作、Commit 收尾和业务结果有效性之间的结构关系图 — 图1：事务结果边界结构说明图，展示 Commit 成功与失败时业务结果和错误返回的静态关系；不是运行截图或执行证据。

先看 Commit 失败改变了什么

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

收尾结果	调用方应该怎么理解	业务动作
`Commit` 返回 nil	事务结果已确认	返回成功结果
`Commit` 返回错误	事务内结果不可继续使用	返回错误，按幂等与补偿策略处理
`Rollback` 返回错误	事务仍然不再有效	记录收尾错误，不伪造成功

所以这种写法有问题：

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 错误和提交错误都返回给调用方，回滚只承担兜底收尾职责。若回滚本身失败，仍然不能把函数改成成功；应通过日志、指标或上层错误链记录它。