Go sql.Tx 怎样处理提交和回滚分支

当一次业务写入要同时修改订单、库存和操作记录时，最容易出错的不是 SQL 语句本身，而是成功与失败的出口没有被放在同一个事务边界里。Go 的 database/sql 用 sql.Tx 表示事务：先通过 DB.Begin 或 DB.BeginTx 开始，再只用 Tx 的方法完成事务内操作；所有操作成功后调用 Commit，任意一步失败则回到 Rollback。

官方地址：https://go.dev/doc/database/execute-transactions

先判断事务到底要保护什么

事务适合保护一个必须整体成立的业务事实。例如创建订单时，订单行已经写入但库存没有扣减，或者库存扣了但订单没有生成，都会留下半完成状态。把这些写操作放进一个 sql.Tx，目标不是让单条 SQL 变快，而是让多次操作的结果具有“全部生效或全部不生效”的边界。

如果只是读取一个独立值，或者两次写入之间没有一致性约束，就不必为了形式套事务。先明确业务负载，再决定事务范围，能避免长事务占用连接。

把事务边界画清楚

BeginTx 返回的 *sql.Tx 代表这次事务。事务里的查询、更新和预处理语句都应通过这个对象完成；直接改用 sql.DB，可能拿到另一个连接，读到事务外的状态，也会让代码的原子边界变得不可见。

可以把控制流收敛成三层：最外层取得事务并负责释放，中间层只做事务内读写，最内层把业务错误原样带回。这样每个失败点都能落到同一条回滚路径上。

推荐的提交与回滚骨架

下面的写法把回滚放进 defer，让所有提前返回都具备兜底路径。提交成功后事务已经结束，延迟执行的 Rollback 会返回 sql.ErrTxDone；这类结果可以忽略。真正需要返回给调用方的是事务内操作错误或 Commit 错误。

package order

import (
	"context"
	"database/sql"
	"fmt"
)

// CreateOrder 将订单和库存修改放进同一条事务边界。
func CreateOrder(ctx context.Context, db *sql.DB, albumID, customerID int64) (err error) {
	// BeginTx 让事务继承调用方的取消和超时信号。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return fmt.Errorf("begin transaction: %w", err)
	}
	// 任意提前返回都会走到这里；Commit 成功后 Rollback 只是结束态提示。
	defer func() {
		_ = tx.Rollback()
	}()

	// 事务内的读必须使用 tx，避免读到事务外的连接状态。
	var stock int64
	if err = tx.QueryRowContext(ctx, "SELECT stock FROM album WHERE id = ?", albumID).Scan(&stock); err != nil {
		return fmt.Errorf("read stock: %w", err)
	}
	if stock 

这个骨架的核心是“先注册回滚兜底，再在最后提交”。不要在中途手写多个互相覆盖的回滚分支，也不要在 Commit 之后继续使用 tx 查询数据。

三类结果要分开处理

• 开始失败：BeginTx 没有返回事务，直接返回错误，不需要调用回滚。
• 事务内操作失败：查询、更新或插入出现错误，提前返回，让延迟回滚释放当前事务。
• 提交失败：不要把它当成普通业务失败后马上安全重试；调用方应记录上下文，并依据驱动和数据库的语义决定恢复策略。

官方文档特别强调：如果 Commit 返回错误，事务里的查询结果和更新结果都不应继续当作有效结果使用。也就是说，函数不能先把“订单已创建”的消息发出去，再去判断提交是否成功。

不要把 DB 方法和 Tx 方法混在一起

事务开始后，相关查询和写操作都应该使用 tx.QueryContext、tx.QueryRowContext、tx.ExecContext 等方法。若中途调用 db.ExecContext，这条语句就不属于当前事务，可能形成部分提交或互相等待。

同样要注意结果集资源的生命周期：在事务内调用 QueryContext 后，应尽快遍历并关闭 Rows，不要让事务长时间占着连接等待无关工作。事务范围越大，连接池越容易被慢查询、网络调用或人工等待拖住。

提交与回滚的边界图

把“操作错误”和“提交错误”分开，是排查事务问题时最有价值的判断。操作错误通常可以沿着业务错误返回；提交错误意味着最终状态没有被调用方确认，应该保留足够的请求标识和数据库上下文供后续处理，而不是盲目把同一组写操作执行第二遍。

落地前的五项检查

1. 事务是否覆盖了必须一起成立的全部写操作？
2. 事务开始后，相关查询和更新是否全部使用 tx？
3. 每个提前返回点是否都有回滚兜底？
4. Commit 的错误是否被返回并记录，而不是被忽略？
5. 事务中是否混入了慢网络调用、长时间计算或不必要的查询？

总结与常见问题

sql.Tx 的正确使用可以归纳为：BeginTx 开始，事务内只使用 Tx 方法，所有失败出口回滚，全部成功后提交，并把提交失败视为未确认结果。这样的结构既能保持数据库连接边界清楚，也能让后续排错有明确入口。

Commit 成功后还需要手动 Rollback 吗？不需要。可以保留延迟回滚作为兜底，它在提交成功后的结束态通常只返回 sql.ErrTxDone，不会撤销已经提交的事务。

Rollback 返回错误要不要覆盖原错误？通常不要直接覆盖原始业务错误。可以记录回滚错误，但应优先保留导致提前返回的根因。

事务里能调用外部 HTTP 接口吗？技术上可以，但通常不建议。外部调用的延迟会长时间占用数据库连接，更稳妥的做法是缩短事务，并用状态表、消息或补偿机制协调跨系统动作。