如何在Golang中处理数据库事务错误_Golang事务回滚与异常处理

事务提交失败时，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()，否则跨连接无效

# ai  # 是在  # 很多人  # 大数据  # 多个  # 也会  # 都要  # go  # golang  # Error  # if  # 字符串  # nil  # 数据库  # 报错  # 死锁  # 重试  # 作用域  # switch  # 返回值  # mysql  # sql  # postgresql  # database  # 应用层  # number  # sqlite 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】