如何在Golang中处理数据库事务错误_回滚和日志记录_技术教程

Go事务需显式提交或回滚，推荐defer安全回滚+逐步错误检查+结构化日志（含tx_id、SQL、堆栈），并封装WithTx模板统一管理。

在 Go 中处理数据库事务错误、回滚和日志记录，核心是确保事务的原子性，并在出错时及时回滚，同时留下可追溯的操作日志。关键不在“捕获 panic”，而在于主动检查错误、显式控制事务生命周期、结构化记录上下文。

事务开始后必须显式提交或回滚

Go 的 database/sql 没有自动回滚机制。一旦调用 db.Begin()，就必须对返回的 *sql.Tx 显式调用 Commit() 或 Rollback() —— 即使函数提前 return，也必须保证其中一者被执行，否则连接可能被占用，甚至导致事务长时间挂起。

推荐用 defer tx.Rollback() 开头，再在成功路径末尾用 tx.Commit() 覆盖；这样即使中间 panic 或 return，也能兜底回滚
注意：tx.Rollback() 在事务已提交或已回滚后再次调用会返回 sql.ErrTxDone，需忽略该错误（不是业务异常）
避免在 defer 中直接写 tx.Rollback() 而不判断状态，应包装为安全回滚函数

错误检查要覆盖每一步执行操作

事务中每个 SQL 操作（tx.Exec、tx.QueryRow、tx.Prepare 等）都可能失败。不能只检查最后一步，也不能用 _ = tx.Exec(...) 忽略错误。

每步操作后立即检查 error，任一失败即应中断流程并回滚
不要把多个语句塞进一个 Exec（如用分号拼接），这不利于错误定位和回滚粒度控制
若需条件分支执行不同语句，应在 error 检查后决定是否继续，而非靠 defer 统一回滚

日志需包含事务 ID、操作上下文与错误堆栈

单纯打印 "failed to insert user" 毫无调试价值。理想日志应能关联一次请求、还原执行路径、明确失败点。

使用结构化日志库（如 zap 或 zerolog），记录 tx_id（可用 uuid.NewString() 生成）、SQL 模板、参数、耗时、错误类型与完整 stack trace
在事务入口处打 start 日志（含 traceID），在 Commit / Rollback 后打结束日志（标注 success 或 failed + error message）
对敏感字段（如密码、token）做日志脱敏，避免误打明文

封装可复用的事务执行模板

重复写 Begin → defer Rollback → check error → Commit 易出错。建议封装为带上下文和日志器的函数：

func WithTx(ctx context.Context, db *sql.DB, logger *zap.Logger, fn func(*sql.Tx) error) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        logger.Error("failed to begin tx", zap.Error(err))
        return err
    }
    defer func() {
        if p := recover(); p != nil {
            logger.Error("panic in tx", zap.Any("panic", p), zap.String("tx_id", getTxID(tx)))
            tx.Rollback()
            panic(p)
        }
    }()
    if err := fn(tx); err != nil {
        logger.Error("tx failed", zap.Error(err), zap.String("tx_id", getTxID(tx)))
        tx.Rollback()
        return err
    }
    return tx.Commit()
}

调用时只需传入业务逻辑闭包，无需手动管理生命周期，错误和日志统一收口。