Go database/sql 事务里怎么区分 Commit 和 Rollback 错误

Go 的 database/sql 事务里，业务语句失败、Rollback 失败和 Commit 失败不是同一种问题。最稳妥的处理顺序是：业务语句出错时先回滚并保留两份错误；提交出错时把事务结果视为“需要核对”，不要因为回滚返回成功就认定数据一定没有写入。

先把三类错误分开：业务、回滚、提交

sql.Tx 里至少有三个需要单独命名的错误边界。第一类是 SQL 执行或扫描失败，例如约束冲突、连接中断或参数错误；第二类是调用 Rollback 时清理事务失败；第三类是 Commit 阶段失败。它们对应的补救动作不同，日志也不应只写一条“事务失败”。

用显式分支保留真实错误来源

业务分支里要先保存原始错误，再调用回滚。Go 1.20 及以后可以用 errors.Join 把两份原因交给上层；如果项目还要兼容更早版本，也可以用结构化日志分别记录，不要用回滚错误覆盖业务错误。

func changeStatus(ctx context.Context, db *sql.DB, id int64) (err error) {
	// BeginTx 失败时没有事务可回滚，直接返回初始化错误。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return fmt.Errorf("begin transaction: %w", err)
	}

	// 兜底清理只负责收尾；显式失败分支仍要单独处理回滚错误。
	defer func() {
		if rollbackErr := tx.Rollback(); rollbackErr != nil && !errors.Is(rollbackErr, sql.ErrTxDone) && err == nil {
			err = fmt.Errorf("rollback: %w", rollbackErr)
		}
	}()

	if _, err = tx.ExecContext(ctx,
		"UPDATE account SET status = ? WHERE id = ?", "active", id); err != nil {
		// 这里的 err 是业务操作错误，不能被 Rollback 的结果替换。
		rollbackErr := tx.Rollback()
		if rollbackErr != nil && !errors.Is(rollbackErr, sql.ErrTxDone) {
			return errors.Join(
				fmt.Errorf("update account: %w", err),
				fmt.Errorf("rollback: %w", rollbackErr),
			)
		}
		return fmt.Errorf("update account: %w", err)
	}

	if err = tx.Commit(); err != nil {
		// 提交失败可能处于未知状态，交给上层按幂等键核对。
		return fmt.Errorf("commit: %w", err)
	}
	return nil
}

这个示例里有一个容易忽略的细节：显式失败分支已经调用过 Rollback，随后 defer 再调用一次通常只会得到 sql.ErrTxDone，因此被忽略。生产代码也可以把回滚封装成一个小函数，统一输出 operation_error 和 rollback_error 两个字段。

Commit 失败时为什么要先查状态

Commit 返回错误，说明调用方没有拿到“已提交”的可靠确认，但它不等于“肯定没有提交”。网络中断、驱动返回失败或数据库在提交边界发生故障时，客户端可能不知道服务端究竟完成到了哪一步。此时直接重试转账、扣库存或发货，很容易把一次业务请求执行两遍。

更安全的动作是记录业务幂等键，查询订单或流水的最终状态；若事务里写入了业务流水，就以流水状态为准。只有确认事务没有产生业务结果，且操作本身具备幂等保护时，才进入重试队列。不要把 Rollback 的返回值当作提交状态证明，因为提交调用已经改变了问题边界。

一张检查清单避免错误互相覆盖

• 是否区分了 BeginTx、业务语句、Rollback 和 Commit 的错误字段？
• 业务失败时，日志里是否同时有业务主键、原始错误和回滚错误？
• 提交失败时，是否保存了幂等键，并安排了状态查询或人工对账？
• 重试策略是否要求“确认未落库”而不是只看客户端错误？

常见问题

defer tx.Rollback() 会不会把 Commit 的成功判成失败？

不会，只要忽略 sql.ErrTxDone。提交或回滚结束后事务已经完成，兜底回滚只是在遗漏分支时帮忙清理。

Rollback 返回错误时应该覆盖原始业务错误吗？

不应该。原始业务错误解释了为什么进入失败分支，回滚错误解释了清理是否成功，最好分别记录或用 errors.Join 保留两者。

Commit 失败后能不能马上再执行一次？

不能默认这样做。先按幂等键核对订单、流水或库存状态；只有确认没有业务结果，且重试不会重复副作用时，才重新投递。