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" 毫无调试价值。理想日志应能关联一次请求、还原执行路径、明确失败点。
立即学习“go语言免费学习笔记（深入）”；
- 使用结构化日志库（如
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()
}
调用时只需传入业务逻辑闭包，无需手动管理生命周期，错误和日志统一收口。
