事务提交失败时，tx.Commit() 一定会返回错误；必须显式检查其返回值并处理，否则事务状态未知，且需避免defer中无条件回滚。
事务提交失败时，tx.Commit() 一定会返回错误
很多人误以为只要 tx.QueryRow() 或 tx.Exec() 出错，事务就自动回滚了——其实不会。*sql.Tx 不会自动管理回滚逻辑，必须显式调用 tx.Rollback()。而真正决定事务是否生效的，是 tx.Commit() 的返回值：它可能因网络中断、连接关闭、底层 SQL 错误（如唯一约束冲突）等返回非 nil 错误。
常见错误现象：tx.Commit() 返回 sql.ErrTxDone（说明已回滚或已提交）、driver.ErrBadConn（连接失效）、或具体数据库错误（如 PostgreSQL 的 pq.Error）。这些都意味着事务未成功持久化。
- 务必检查
tx.Commit()的返回值，不能忽略 - 若
tx.Commit()报错，且此前未手动Rollback()，说明事务处于未知状态，应按失败处理 - 不要在
defer tx.Rollback()后直接Commit()—— 这会导致无论成功与否都先回滚一次
正确使用 defer 避免重复回滚和资源泄漏
最安全的模式是：只在明确知道事务尚未提交时才回滚，且确保只回滚一次。典型做法是在开启事务后立即设一个标志，并用 defer 做条件回滚。
tx, err := db.Begin()
if err != nil {
return err
}
defer func() {
if err != nil {
tx.Rollback()
}
}()
_, err = tx.Exec("INSERT INTO users(name) VALUES($1)", "alice")
if err != nil {
return err // 此处 return 会触发 defer 中的 Rollback
}
err = tx.Commit() // 成功则 err == nil，defer 不执行 Rollback
return err
这个结构的关键在于：把 err 作用域延伸到 defer 内部，靠函数返回前的 err 值判断是否需要回滚。它避免了手动写 if err != nil { tx.Rollback() } 在每个错误分支重复出现，也防止 Commit() 失败后遗漏回滚。
-
defer中不能直接调用tx.Rollback()无条件执行，否则Commit()成功后也会被回滚 - 不要用
recover()捕获 panic 后再回滚——Go 数据库操作不抛 panic，panic 是应用层异常，不应混入事务控制流 - 如果事务中调用了外部函数并担心 panic，应在该函数外加
defer+recover()，但回滚逻辑仍应由上述 err 控制
区分数据库错误类型以决定是否重试或告警
不是所有事务错误都该重试。例如唯一键冲突（UNIQUE_VIOLATION）通常是业务逻辑问题，而连接超时（context.DeadlineExceeded）或临时死锁（PostgreSQL 的 deadlock_detected）才适合重试。
以 PostgreSQL 为例，需类型断言 err 为 *pq.Error 才能拿到 Code：
if pqErr, ok := err.(*pq.Error); ok {
switch pqErr.Code {
case "23505": // unique_violation
return fmt.Errorf("user already exists")
case "40P01": // deadlock_detected
return fmt.Errorf("deadlock, retry recommended")
}
}
- MySQL 用户应检查
mysql.MySQLError的Number字段（如1062表示重复键） - SQLite 用户注意：其错误码较粗粒度，常需结合
err.Error()包含的字符串匹配（如"UNIQUE constraint failed"） - 任何重试逻辑都必须带指数退避和最大次数限制，否则可能放大数据库压力
嵌套事务与 Savepoint 不被标准 database/sql 支持
database/sql 的 Begin() 只支持扁平事务，没有内置 savepoint 或嵌套事务语义。所谓“子事务”只能靠数据库原生命令模拟，且行为高度依赖驱动和数据库版本。
例如在 PostgreSQL 中可手动执行：
_, err := tx.Exec("SAVEPOINT sp1")
// ... 中间操作
if err != nil {
_, _ = tx.Exec("ROLLBACK TO SAVEPOINT sp1") // 注意：这不会影响 err 状态
}
但这种写法脆弱：一旦 tx 连接中断，savepoint 就失效；且 ROLLBACK TO SAVEPOINT 自身也可能报错，无法保证回滚成功。
- 除非强需求且团队熟悉目标数据库的 savepoint 行为，否则应避免在应用层模拟嵌套事务
- 更稳妥的方式是拆分为多个独立事务，用业务状态表或消息队列保证最终一致性
- 所有 savepoint 相关 SQL 必须用
tx.Exec()而非db.Exec()，否则跨连接无效
Commit() 
和 Rollback() 调用都要对应一次明确的状态决策，而不是依赖“应该没问题”的假设。
