Go sql.Tx 回滚失败时怎样保留原始业务错误

平时在Go的数据库事务开发过程中，我们经常碰到业务代码执行出错，调用事务回滚方法时又返回额外错误的场景，这时候很容易把最初的业务原始错误覆盖掉，要解决这个问题，你可以通过错误优先级标记、多错误合并的编码方式，优先保留业务层抛出的原始错误，再兜底记录回滚过程产生的异常信息。

事务执行过程中如果业务逻辑先返回错误，回滚操作抛出的错误不应该覆盖原始业务错误，可以把回滚错误作为附属信息附加到原始错误返回，优先向外透传业务逻辑本身的报错，方便问题定位。

Go 里最容易丢失的一类错误，是“业务操作先失败，回滚又失败”。如果直接写成 tx.Rollback() 后返回原错误，回滚失败没有记录；如果把回滚错误赋给返回值，又可能把真正的业务原因覆盖掉。更稳妥的做法是保留原始业务错误，把回滚错误作为第二个原因组合返回，并对事务已经结束的边界单独处理。

为什么不能让 Rollback 错误覆盖业务错误

假设订单扣库存时先收到 ErrStockNotEnough，随后数据库驱动在回滚阶段又返回连接错误。后一个错误只能说明清理动作出现问题，不能证明库存校验没有失败。调用方往往需要用 errors.Is 判断库存不足并返回明确的业务响应，因此原始错误必须保留下来。

官方 database/sql 文档说明，Tx.Rollback 用于终止事务；即使回滚失败，事务也不再有效，不能把当前 Tx 当作可继续执行的连接。Go 1.20 引入的 errors.Join 会丢弃 nil 值，并允许 errors.Is、errors.As 检查被组合的错误。

用 defer 统一处理失败路径

下面的写法让所有中途返回的错误都经过同一个清理出口。关键点是使用命名返回值 err，只有返回错误时才调用回滚；回滚成功则保持原错误不变，回滚失败才追加第二个错误。

func createOrder(ctx context.Context, db *sql.DB) (err error) {
	// 事务只负责这一条业务链，离开函数后不再复用 Tx。
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer func() {
		if err == nil {
			return // Commit 已成功，不能把清理错误误当成业务错误。
		}
		if rollbackErr := tx.Rollback(); rollbackErr != nil && !errors.Is(rollbackErr, sql.ErrTxDone) {
			// 保留原始业务错误，同时附带回滚失败原因。
			err = errors.Join(err, fmt.Errorf("rollback transaction: %w", rollbackErr))
		}
	}()

	if _, err = tx.ExecContext(ctx, "INSERT INTO orders ..."); err != nil {
		return err // defer 会负责回滚，不覆盖这条错误。
	}
	if _, err = tx.ExecContext(ctx, "UPDATE inventory ..."); err != nil {
		return err
	}
	if err = tx.Commit(); err != nil {
		// Commit 失败代表结果需要核对，不能假设事务已回滚。
		return err
	}
	return nil
}

示例中的 SQL 省略了具体字段，只突出错误边界。生产代码还应把订单号、操作名和数据库驱动错误码作为结构化日志字段，避免只记录拼接后的长字符串。

errors.Join 后怎样判断具体原因

组合错误不是只能展示文本。调用方仍可以匹配业务哨兵错误，也可以提取驱动返回的结构化错误。这样既能给用户稳定的业务提示，又能给运维留下回滚异常线索。

如果项目仍支持 Go 1.19 或更早版本，可以定义包含 Primary 和 Cleanup 字段的自定义错误，并实现 Unwrap；不要为了兼容旧版本而静默丢掉回滚错误。

Commit 失败和重复回滚要分开看

Commit 返回错误时，不能简单归类为“已经回滚”。官方事务说明建议丢弃事务中的查询结果，并把提交失败视为需要确认的状态；此时再由 defer 调用 Rollback，常见结果可能是 sql.ErrTxDone。因此上面的代码专门忽略这个清理阶段的已结束错误，避免日志看起来像又发生了一次新的业务故障。

最终的检查清单很短：原始业务错误是否仍可被 errors.Is 匹配；回滚失败是否进入日志或告警；Commit 失败是否进入核对流程；同一个 Tx 是否没有被再次使用。

相关问题

Rollback 返回 sql.ErrTxDone 要不要覆盖原错误？

通常不要。它多半表示事务已经提交、回滚或被上下文取消，保留原始错误更有助于调用方判断；只有排查清理时机时才单独记录它。

errors.Join 会不会让 errors.Is 失效？

不会。Go 1.20+ 的 errors.Join 支持多错误展开，errors.Is 和 errors.As 仍可遍历其中的错误。

回滚失败是否代表数据一定提交了？

不代表。它只说明回滚动作没有成功返回；事务已经不可继续使用，但最终数据状态仍应结合驱动、数据库和业务补偿记录核对。