Golang事务回滚与错误处理技巧

在 Go 的 database/sql 中，事务回滚绝非自动发生——SQL 执行失败不会触发回滚，必须手动调用 tx.Rollback() 并严谨处理每一步 error；常见陷阱包括忽略错误、误用 defer 导致重复回滚、忽视 Rollback 自身可能失败、盲目依赖 recover 捕获数据库异常，以及遗漏超时控制和 Savepoint 的数据库兼容性细节；真正健壮的事务处理，始于对 error 的即时响应、提交/回滚逻辑的精确分支控制、rollback 错误的合理降级处理、上下文超时的强制约束，以及 savepoint 等高级功能的手动谨慎封装。

事务提交失败时，tx.Commit() 才会返回错误

很多人误以为只要 SQL 执行出错，事务就自动回滚。实际上 Go 的 database/sql 中，*sql.Tx 是手动控制的：只有调用 tx.Commit() 或 tx.Rollback() 才真正结束事务。SQL 执行失败（比如 tx.Exec() 返回 error）并不会自动回滚，也不会终止事务——你仍需显式调用 tx.Rollback()，否则连接可能被卡住，甚至引发连接池耗尽。

典型错误写法：

tx, _ := db.Begin()
tx.Exec("INSERT INTO users(name) VALUES(?)", "alice") // 错误被忽略
tx.Exec("INSERT INTO users(name) VALUES(?)", "bob")   // 假设这里违反唯一约束
tx.Commit() // 此时才报错，但前一条已生效？不，其实两条都在同一事务中，但错误没被检查！

正确做法是：每一步都检查 error，并在出错时立即 tx.Rollback()。

用 defer + recover 无法捕获 SQL 错误，必须显式判断 error

Go 没有类似 Java 的 checked exception，所有数据库错误都是返回 error 值，不是 panic。试图用 defer func() { if r := recover(); r != nil { ... } }() 来兜底事务，完全无效——SQL 错误不会 panic。

常见误区：

• 以为 defer tx.Rollback() 能“自动回滚”，却忘了它会在 tx.Commit() 成功后也执行，导致二次 rollback 报错（sql: transaction has already been committed or rolled back）
• 把 defer 放在 tx.Begin() 后就不管了，没结合成功/失败分支逻辑

安全模式是：用一个布尔标记是否已提交，或用闭包封装 commit/rollback 逻辑。

tx.Rollback() 本身也可能返回 error，但通常可忽略

tx.Rollback() 在事务已提交、已回滚、或底层连接断开时会返回 error。大多数情况下，你只关心“是否成功回滚了本次操作”，而不在意 rollback 自身失败——因为此时事务状态已不可控，日志记录 + 告警比重试更合理。

建议写法：

err := tx.Commit()
if err != nil {
    rollbackErr := tx.Rollback()
    if rollbackErr != nil {
        log.Printf("tx.Rollback() failed after Commit() error: %v", rollbackErr)
    }
    return err
}

注意：tx.Rollback() 不会覆盖原始 Commit() 的 error，所以要先保存 err 再调用 rollback。

嵌套事务不被原生支持，Savepoint 需驱动层配合

database/sql 没有内置 savepoint 支持。像 PostgreSQL 的 SAVEPOINT sp1 和 ROLLBACK TO SAVEPOINT sp1 必须手动用 tx.Exec() 发送，且不同数据库语法不同（MySQL 用 SAVEPOINT sp1，SQLite 也支持，但 SQL Server 不直接暴露）。

如果你需要局部回滚，得自己管理：

• 确认驱动支持（pgx、pq、mysql 一般支持；sqlite3 支持但要注意 WAL 模式限制）
• 显式执行 tx.Exec("SAVEPOINT sp_name")
• 出错时执行 tx.Exec("ROLLBACK TO SAVEPOINT sp_name")，而不是 tx.Rollback()
• RELEASE SAVEPOINT 不是必须的，但不释放可能影响性能（尤其长事务）

没有通用抽象层，硬上 savepoint 容易和数据库版本、隔离级别耦合。

事务最常被忽略的一点：超时控制。无论是 db.SetConnMaxLifetime() 还是上下文 context.WithTimeout() 传给 db.BeginTx()，一旦事务卡住，连接不会自动归还。真正的健壮性不在 rollback 多完美，而在不让事务活过它的 deadline。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang事务回滚与错误处理技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。