Go database/sql 事务提交失败时怎么保证回滚

Go 的 database/sql 事务要想“出错就回滚”，关键不是在每个分支手写一遍 Rollback，而是先用 defer tx.Rollback() 覆盖所有提交前的提前返回，再单独处理 Commit 返回错误的未知状态。提交成功后，修改才被当作一次完整的原子变更；提交失败时，事务内的查询结果和写入结果都不能继续当成可信数据。

能保证的是：事务尚未提交时，任何业务错误都会触发回滚。不能保证的是：Commit 已返回错误后，应用还能凭一次 Rollback 判断数据库到底有没有落盘。这个分界决定了后续要做对账和幂等，而不是盲目重试。

事务提交失败时，回滚并不总能补救

sql.Tx 的生命周期只有两个正常出口：Commit 或 Rollback。在扣库存、写订单这类场景中，事务内部的 SQL、QueryRowContext 和业务校验只要有一个失败，就应该让函数带着错误返回，并由延迟回滚清理未提交的修改。

但 Commit 是边界事件。它返回 nil，可以把本次结果交给上层；它返回错误，应用层无法仅凭这个错误断言数据库一定没有应用修改。Go 官方文档建议丢弃事务内结果，因此提交错误更适合进入“未知状态”路径。

用 defer tx.Rollback 覆盖所有提交前错误

推荐把回滚放在成功开启事务之后，紧接着写入 defer。这样无论库存检查、扣减还是订单写入在哪一步提前返回，都不会遗漏清理。延迟调用在提交成功后执行时，事务已经结束，回滚返回的 sql.ErrTxDone 通常可以忽略。

func CreateOrder(ctx context.Context, db *sql.DB, userID, skuID int64) error {
	// 用请求上下文开启事务，避免数据库操作脱离调用方生命周期。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return fmt.Errorf("begin transaction: %w", err)
	}
	// 所有提交前的提前返回都会走这里；提交成功后该调用不再改变结果。
	defer tx.Rollback()

	var stock int
	if err := tx.QueryRowContext(ctx,
		"SELECT stock FROM inventory WHERE sku_id = ?", skuID).Scan(&stock); err != nil {
		// 查询失败直接返回，defer 负责回滚。
		return fmt.Errorf("read inventory: %w", err)
	}
	if stock 

这里的顺序有两个细节：第一，事务内所有 SQL 都使用 tx，否则一条写操作可能已经在事务外生效；第二，Commit 的错误必须继续向上返回，不能用“再 Rollback 一次”把它改写成确定的回滚结果。

Commit 返回错误后如何判断下一步

提交错误的处理重点从“回滚”转成“不要重复造成副作用”。例如订单接口可以先生成业务幂等键，把订单号或请求号写入唯一约束字段；提交错误后，由后台对账按这个键查询最终状态。查到已存在就返回已完成，查不到也不要立刻无限重试，而是根据驱动、数据库和业务补偿策略决定是否重放。

如果回滚本身返回错误，也应该记录它，但不要把日志误读为“事务可能又提交了”。事务结束后，sql.Tx 已经失效；真正需要确认的是业务数据最终状态，而不是继续在这个 tx 上执行查询。

把回滚语义落到工程检查清单

封装公共事务函数时，可以把下面四条作为代码评审清单：开启事务后立即注册延迟回滚；所有数据库调用使用 tx 版本；提交成功前不向消息队列、缓存或调用方宣布成功；提交错误使用请求幂等键、状态表或补偿任务收敛结果。

还要避免直接在字符串里执行 BEGIN、COMMIT，也不要在事务中混用 db.Query。这些做法会让连接和事务边界交给应用的偶然行为，遇到并发、超时或连接回收时更难判断。

常见问题

提交成功后 defer tx.Rollback 会不会把数据撤销？

不会。提交成功后事务已经结束，延迟回滚通常只会得到事务已完成的结果，不会撤销已提交的数据。

Commit 失败后还要不要显式调用 Rollback？

不要把它当成确定性补救。提交失败后的事务结果应视为无效或未知，重点是记录幂等信息并对账；重复调用还可能只得到 sql.ErrTxDone。

能不能捕获 Commit 错误后自动重试整个事务？

只有在业务写入具备幂等约束、能接受重复请求并且有最终状态查询时才考虑重试。否则重试可能把一次实际成功变成两次订单或两次扣减。