当前位置：首页 > 文章列表 > Golang > Go教程 > Go database/sql 事务提交失败时怎么保证回滚

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

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

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

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

要点速览

事务必须通过 sql.Tx 的方法执行，不能把同一组写操作混回 sql.DB。
defer tx.Rollback() 可以兜住查询、更新、业务校验等提交前错误；提交成功后它会成为无效操作。
Commit 失败时不要返回“已回滚”的假结论，应依靠业务幂等键、状态表或对账任务恢复确定性。

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

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

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

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

Go database/sql 事务边界图，展示 BeginTx、Tx.ExecContext、defer Rollback 与 Commit 的关系 — 图1：静态关系图展示提交前错误由 Rollback 收口，Commit 成功才把结果交给业务层。

推荐把回滚放在成功开启事务之后，紧接着写入 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 返回错误后如何判断下一步

Go sql.Tx 提交错误关系图，连接未知状态、业务幂等键、对账查询与重试策略 — 图2：提交错误后的静态决策关系，重点是把未知状态交给幂等和对账组件处理。

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

错误位置	应该做什么	不要做什么
BeginTx 失败	直接返回，记录连接或上下文错误	调用不存在的 tx.Rollback
Commit 前 SQL 失败	返回原错误，延迟回滚	改用 db.Exec 补写
Commit 返回错误	丢弃事务结果，进入对账/幂等路径	声称已回滚或无条件重试

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