事务提交失败后如何保证回滚

Go 的事务回滚不能只靠“某条 SQL 报错后调用一次 Rollback”。更稳妥的做法是：用 BeginTx 建立事务，把所有读写都放在同一个 *sql.Tx 上，函数开始后立即注册 defer tx.Rollback()，只有全部步骤成功才调用 Commit。如果 Commit 本身返回错误，就把本次事务里的结果视为不可用，直接向上返回。

官方资料：https://go.dev/doc/database/execute-transactions；API 说明：https://pkg.go.dev/database/sql#Tx。

核心原则是“失败路径默认回滚，成功路径最后提交”。中途业务错误由延迟回滚兜底，提交阶段的错误必须单独判断，不能把它当成普通查询错误继续处理。

先把事务边界固定在 BeginTx

database/sql 的事务对象是 *sql.Tx。它代表一次进行中的事务，并且必须以 Commit 或 Rollback 结束。使用带上下文的 BeginTx，可以让请求超时或客户端取消时的事务更容易收敛。

func CreateOrder(ctx context.Context, db *sql.DB, userID, amount int64) (int64, error) {
	// 用请求上下文开始事务；取消请求时，数据库操作也能收到取消信号。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return 0, fmt.Errorf("begin transaction: %w", err)
	}

	// 任何提前返回都会执行回滚；成功 Commit 后这里的 Rollback 不再生效。
	defer tx.Rollback()

	// 后续步骤只使用 tx，不要改回 db。
	return createOrderInTx(ctx, tx, userID, amount)
}

这里的 defer 不是为了把提交失败“变成成功”，而是为所有提前返回建立统一的清理路径。开始事务失败时还没有可回滚的 Tx，所以要在注册延迟函数之前直接返回。

事务中的每一步都要使用 Tx

最容易被忽略的错误是：事务已经开始，却又调用了 db.ExecContext 或 db.QueryRowContext。这些方法属于连接池对象 *sql.DB，可能使用另一条连接，因此不受当前事务保护。事务内的增删改查应使用 tx.ExecContext、tx.QueryContext 或 tx.QueryRowContext。

func createOrderInTx(ctx context.Context, tx *sql.Tx, userID, amount int64) (int64, error) {
	// 先检查库存，读取也必须通过同一个 Tx。
	var stock int64
	if err := tx.QueryRowContext(ctx,
		"SELECT stock FROM inventory WHERE sku = ? FOR UPDATE", "book-1").Scan(&stock); err != nil {
		return 0, fmt.Errorf("load stock: %w", err)
	}
	if stock 

如果其中一条语句使用了 db，就可能出现订单回滚了但库存已经在事务外改变的情况。代码审查时，可以先搜索事务函数里是否混用了 db. 和 tx.，这是很高价值的检查项。

为什么要一开始就 defer Rollback

事务函数通常有多个失败分支：查询没有结果、库存不足、更新失败、读取自增 ID 失败等。逐个手写 Rollback 容易漏掉某一条返回路径。把回滚放在事务开始后，可以让所有后续的 return err 自动经过同一条兜底路径。

func CreateOrder(ctx context.Context, db *sql.DB, userID, amount int64) (orderID int64, err error) {
	// 事务开始失败时没有 Tx，不能调用 Rollback。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return 0, err
	}
	// 提交前任一 return 都会尝试回滚；成功提交后 Rollback 返回 sql.ErrTxDone，可忽略。
	defer func() {
		_ = tx.Rollback()
	}()

	if _, err = tx.ExecContext(ctx, "UPDATE accounts SET balance = balance - ? WHERE id = ?", amount, userID); err != nil {
		return 0, fmt.Errorf("debit: %w", err)
	}
	if _, err = tx.ExecContext(ctx, "INSERT INTO ledger(account_id, amount) VALUES (?, ?)", userID, amount); err != nil {
		return 0, fmt.Errorf("write ledger: %w", err)
	}
	if err = tx.Commit(); err != nil {
		// Commit 失败时不要继续使用 orderID 或其它事务结果。
		return 0, fmt.Errorf("commit: %w", err)
	}
	return orderID, nil
}

也可以直接写成 defer tx.Rollback()。如果希望明确表达“延迟回滚错误不是主错误”，可以像上面的示例一样用闭包丢弃返回值。重点不在于吞掉业务错误，而在于不让清理动作覆盖真正的失败原因。

Commit 失败时应该怎么判断

Commit 是最终结论点。它返回 nil，才表示事务提交成功；一旦返回错误，调用方不应继续使用事务中读到的结果，也不应再把同一 Tx 当作可用对象。官方文档还特别指出，即使 Rollback 自己返回错误，事务也不会重新变成有效状态。

func finalize(tx *sql.Tx) error {
	// Commit 成功才把本次事务视为完成。
	if err := tx.Commit(); err != nil {
		// 提交结论未知或失败时，返回错误并让上层决定是否重试。
		return fmt.Errorf("commit transaction: %w", err)
	}
	return nil
}

不要把“某个 ExecContext 返回 nil”理解为整个事务已经成功。它只说明该语句在事务上下文中执行成功，最终状态仍由 Commit 决定。

context 取消和回滚失败要分开看

BeginTx 使用的上下文会影响事务生命周期。如果上下文被取消，database/sql 会尝试回滚；此时 Commit 也可能因为上下文已取消而返回错误。业务代码不应把这类错误当作“可以继续提交”的信号。

func saveWithTimeout(parent context.Context, db *sql.DB) error {
	// 给一次事务设置明确的时间上限，避免请求一直占住连接。
	ctx, cancel := context.WithTimeout(parent, 3*time.Second)
	defer cancel()

	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer tx.Rollback()

	// 所有数据库调用沿用 ctx，超时后不要切换到 context.Background 重试同一 Tx。
	if _, err := tx.ExecContext(ctx, "UPDATE jobs SET state = ? WHERE id = ?", "done", 42); err != nil {
		return fmt.Errorf("update job: %w", err)
	}
	if err := tx.Commit(); err != nil {
		return fmt.Errorf("commit after context: %w", err)
	}
	return nil
}

如果业务需要自动重试，应在事务函数外重新开始一次完整事务，并配合幂等键或唯一约束，不能复用已经执行过 Commit 或 Rollback 的 Tx。一旦事务结束，继续操作会得到 sql.ErrTxDone。

最后用一张表检查失败路径

因此，回答“事务提交失败后如何保证回滚”时，关键不是再补一行孤立的 Rollback，而是把事务设计成一条清晰的状态路径：开始成功后默认回滚，所有操作走 Tx，最后只以 Commit 的返回值作为成功依据。

常见追问

• Commit 成功后还需要手动 Rollback 吗？ 不需要；延迟回滚可以保留，成功提交后它不会再改变事务结果。
• Rollback 返回错误要不要覆盖原错误？ 通常不要。应保留原始业务或提交错误，必要时把回滚错误写入日志。
• 可以在事务里调用 db.QueryRow 吗？ 不建议。要保持事务一致性，应改用同一事务对象的 QueryRowContext。