Go database/sql Tx在异常路径统一回滚事务的资源方案

在 Go 的 database/sql 里，异常路径统一回滚的核心写法是：BeginTx 成功后立刻注册一次延迟回滚，业务代码只负责返回错误；全部 SQL 和业务校验通过后再调用 Commit。提交成功后，延迟回滚只会收到事务已完成的状态，不会把已提交的数据撤回。

正常执行流中只要在最后提交事务前给Tx标记已提交状态，defer逻辑里先判断这个标记，非提交状态就自动执行回滚，同时覆盖业务报错、panic、中途return所有异常场景，不需要在每个分支单独处理回滚逻辑。

先把回滚收口到一个 defer

最容易失控的写法，是在插入失败、库存不足、写日志失败等分支分别调用 Rollback。分支一多，总会漏掉一个 return。可以让函数使用命名返回值，延迟函数只在最终错误不为空时回滚；这样成功提交后不会再做一次无意义的回滚。

// CreateOrder 只演示事务边界，不依赖具体数据库驱动。
func CreateOrder(ctx context.Context, db *sql.DB, userID, skuID int64) (err error) {
	// BeginTx 失败时没有可回滚的 Tx，直接返回创建错误。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}

	// 所有中途错误都会经过这里；提交成功后 ErrTxDone 会被忽略。
	defer func() {
		if rbErr := tx.Rollback(); rbErr != nil &&
			!errors.Is(rbErr, sql.ErrTxDone) && err == nil {
			// 只有原本没有业务错误时，才把回滚错误作为返回值。
			err = rbErr
		}
	}()

	// 事务内的写操作必须使用 Tx，不能绕回 db 取得另一条连接。
	if _, err = tx.ExecContext(ctx,
		"INSERT INTO orders(user_id, sku_id) VALUES(?, ?)", userID, skuID); err != nil {
		return err
	}

	// 业务校验失败也走 return，让 defer 负责回滚。
	var stock int
	if err = tx.QueryRowContext(ctx,
		"SELECT stock FROM inventory WHERE sku_id = ? FOR UPDATE", skuID).Scan(&stock); err != nil {
		return err
	}
	if stock 

这段代码需要导入 context、database/sql、errors 和 fmt。这里的回滚是兜底动作，不是业务分支的“补偿事务”：它只负责结束当前 Tx，不会替代库存、订单等领域规则。

为什么事务内不能混用 db 和 tx

sql.DB 是连接池，Tx 代表一次绑定在同一事务上下文中的操作。若插入使用 tx.ExecContext，后续查询却使用 db.QueryRowContext，后一个查询可能拿到池中的另一条连接，看不到未提交写入，也不会随着当前 Rollback 一起撤销。

因此，事务函数里可以保留 db.BeginTx 作为入口，但事务期间的读写、预处理语句和行查询都应从 tx 发起。只有明确不属于该原子操作的统计、异步通知或独立查询，才应移到提交之后，并重新判断它们的失败语义。

提交失败时，回滚错误不能覆盖原始错误

事务提交不是普通的“最后一行代码”。如果 Commit 返回错误，调用方可能无法确定数据库端最终状态：有的驱动已经完成提交，有的仍然处于失败状态。此时应记录事务标识或业务幂等键，让上层按业务策略查询或重试，而不是直接返回“创建成功”。

上面的 defer 无条件尝试 Rollback，但忽略 sql.ErrTxDone。这是为了覆盖两个合法结果：提交成功后回滚会提示事务已完成；提交失败后回滚可能成功，也可能同样提示已完成。无论哪一种，都不能用回滚返回值覆盖更有价值的 Commit 错误。

异常路径的检查清单

• 每个错误都返回：不要在忽略错误后继续执行下一条 SQL。
• 没有提前提交：只有所有原子操作完成后才调用 Commit。
• 查询资源要关闭：使用 tx.QueryContext 得到 Rows 时，仍要根据查询范围及时 Close 并检查 Rows.Err。
• 日志保留上下文：记录业务键、阶段和原始错误；回滚失败可作为附加字段，不要掩盖主错误。
• 超时要传入同一个 ctx：BeginTx、事务 SQL 和提交都应使用符合业务时限的上下文。

常见问题

defer tx.Rollback() 会不会撤销已经 Commit 的事务？

不会。事务提交或回滚后，Tx 已进入完成态，后续回滚通常返回 sql.ErrTxDone；忽略这个收尾结果即可。

为什么不在每个错误分支手动 Rollback？

分支越多越容易漏清理。统一 defer 能覆盖 SQL 错误、业务校验和提前返回，代码也更容易审查。

Commit 返回错误后能不能立即重试？

不要盲目重试。先根据驱动和业务幂等设计确认最终状态；重复写入可能造成重复订单或重复扣减。

参考资料：Go 官方 database/sql 包文档与事务执行指南。本文示例中的表名和字段仅用于说明事务边界，实际锁语义、占位符格式和可重试错误仍以所用数据库驱动文档为准。