事务提交失败时，tx.Commit() 才返回错误；SQL执行出错不会自动回滚，必须显式调用tx.Rollback()，且需检查每步error、避免defer误用、注意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。
立即学习“go语言免费学习笔记（深入）”；
常见误区：
- 以为
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。 
