当前位置：首页 > 文章列表 > Golang > Go教程 > database/sql 事务错误回滚与提交判断的清理清单

database/sql 事务错误回滚与提交判断的清理清单

来源：17golang原创 2026-11-12 18:12:59 0浏览收藏

线上写订单、库存或账务数据时，事务代码最容易漏掉的不是 SQL 本身，而是错误路径：开启失败没有继续判断、执行失败没有回滚、Commit 返回错误却被当成“肯定没写进去”。一份可靠的清理清单应该把这三种状态分开处理：事务尚未开始、事务明确失败、提交结果未知。

要点速览

拿到 *sql.Tx 后立即登记 defer tx.Rollback()，让未提交路径自动收口。
业务操作失败先保留原始错误；回滚失败作为附加信息记录，不要覆盖根因。
Commit 失败不等于数据库一定没有变化，涉及重试时要先确认幂等键和结果查询方案。

先把事务状态和清理责任分开

database/sql 的事务必须以 Commit 或 Rollback 结束。开启阶段的错误不属于“回滚失败”，因为此时通常还没有可供调用的事务对象；进入事务后的错误才需要走回滚路径。用 BeginTx 接收请求上下文，能让取消信号参与事务生命周期，但也意味着上下文取消后不能再把提交结果想当然地当成成功或失败。

Go database/sql 事务从 BeginTx 到 Commit 或 Rollback 的状态边界说明图 — 图1：database/sql 事务状态边界说明图，展示开启、业务执行和结束动作的责任分界。

实际代码可以把兜底回滚放在拿到事务之后。提交成功后，后续的 Rollback 会返回事务已结束一类的错误，因此不要把这个 defer 当成第二次提交；它只是覆盖提前返回和异常分支。

// saveOrder 只展示事务边界；具体驱动和表结构由调用方提供。
func saveOrder(ctx context.Context, db *sql.DB, orderID int64) error {
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		// 开启失败时没有可清理的 Tx，直接返回原始错误。
		return fmt.Errorf("begin transaction: %w", err)
	}
	defer tx.Rollback() // 未提交路径自动回滚；提交后的 ErrTxDone 不改变成功结果。

	if _, err = tx.ExecContext(ctx,
		"UPDATE orders SET status = ? WHERE id = ?", "paid", orderID); err != nil {
		// 业务错误优先保留，回滚只负责释放事务状态。
		return fmt.Errorf("update order: %w", err)
	}
	if err = tx.Commit(); err != nil {
		// Commit 失败可能处于未知状态，不能直接当作“未提交”重放写入。
		return fmt.Errorf("commit transaction: %w", err)
	}
	return nil
}

执行失败时，回滚错误怎么处理

执行语句、扫描结果或业务校验失败，都应该先让 defer 触发回滚，再把原始错误返回。若需要显式记录回滚结果，可以把回滚错误作为日志字段或包装错误的附加信息；不要用“回滚失败”覆盖真正导致订单更新失败的 SQL 错误。只有在回滚本身影响后续补偿判断时，才把两者一起上报。

查询类事务还要把 Rows.Close 和 Rows.Err 纳入检查。行迭代中途发生网络或驱动错误，不能因为已经读到几行数据就继续提交。资源清理和事务清理是两条线：关闭 rows 释放结果集，回滚或提交结束事务。

位置	需要判断	处理动作
`BeginTx`	返回的 error	直接返回，不调用 tx 方法
Exec/Scan/Rows.Err	业务或驱动错误	保留原错误，走回滚兜底
`Rollback`	回滚是否也失败	记录附加错误，标记需要人工或补偿处理
`Commit`	提交返回值	失败按未知状态处理，避免无条件重试

Go database/sql 事务错误清理关系说明图，展示原始错误、回滚结果与提交未知状态的处理关系 — 图2：错误清理关系说明图，区分原始业务错误、回滚附加错误和 Commit 结果未知三种记录。

Commit 失败不要直接按失败重放

Commit 返回错误的危险点在于：调用方可能已经把请求发给数据库，但客户端没有可靠收到最终结果。此时最稳妥的清理清单是记录事务标识、业务幂等键、数据库错误和请求上下文状态，再根据业务查询确认最终状态。支付、库存扣减这类不可重复写入，应该让重试依赖幂等键或补偿任务；普通的网络错误不能自动推出“数据库没有变化”。

如果使用 BeginTx 的 context 被取消，标准库会尝试回滚，提交也可能返回错误。代码层面仍要把这个结果交给上层，而不是在 defer 中偷偷重试。重试策略属于业务协议，必须知道重复执行会不会产生第二条订单、第二次扣减或状态覆盖。