事务Commit失败后Rollback报错是预期行为，因事务对象已进入终态不可再操作；应仅在明确需回滚时调用Rollback且仅一次，并用errors.Is(err, sql.ErrTxDone)区分错误类型。
事务提交失败时，Rollback() 也报错怎么办
直接说结论：事务 Commit() 失败后调用 Rollback() 报错（比如 "sql: transaction has already been committed or rolled back"），不是 bug，是预期行为。根本原因是事务对象已进入终态，不能再操作。
常见错误现象是写成这样：
tx, _ := db.Begin()
defer func() {
if r := recover(); r != nil {
tx.Rollback() // panic 可能发生在 Commit 后，此时 Rollback 会 panic
}
}()
_, err := tx.Exec("INSERT ...")
if err != nil {
tx.Rollback()
return err
}
err = tx.Commit()
if err != nil {
tx.Rollback() // ❌ 错误！Commit 失败不等于事务还活着；某些驱动（如 pgx）此时 tx 已失效
return err
}
- 必须在
Commit()前确保事务处于活跃状态；一旦Commit()或Rollback()返回非 nil 错误，该tx对象不可再用 - 不要依赖
defer tx.Rollback()覆盖所有路径——它可能在Commit()成功后执行，导致二次 rollback 报错 - 正确做法是显式控制流程：只在明确需要回滚的分支里调用
Rollback()，且仅一次
如何安全地捕获 Rollback() 自身的错误
Rollback() 确实可能返回错误（例如网络断连、连接被服务端 kill），但这个错误通常意味着“回滚动作没成功”，不代表数据一定不一致——它只说明你失去了对这次事务结局的确认权。
使用场景很实际：你在做金融类强一致性操作，不能接受“不知道有没有回滚成功”。
立即学习“go语言免费学习笔记（深入）”；
- 先检查
Rollback()返回的 error 是否为sql.ErrTxDone（表示事务早已结束，无需处理） - 其他 error（如
"write: connection reset by peer"）需记录告警，但不应重试 rollback —— 重试无意义，连接已断 - 真正要做的，是在业务层设计幂等性或补偿逻辑，而不是指望靠多次
Rollback()拯救
示例判断：
err := tx.Rollback()
if err != nil && !errors.Is(err, sql.ErrTxDone) {
log.Warn("rollback failed unexpectedly", "err", err)
// 触发人工核查或异步补偿
}
嵌套事务或 Savepoint 场景下，Rollback() 行为差异
Go 标准库 database/sql 不支持真正的嵌套事务，所谓“嵌套”其实是用 Savepoint 模拟。这时 Rollback() 的语义就变了。
典型错误是以为 tx.Rollback() 只回滚到最近 savepoint，结果整个事务被干掉了。
-
tx.Rollback()总是全局回滚，不管有没有设过 savepoint - 要回滚到 savepoint，得用驱动特有方式：比如
pgx是tx.RollbackTo(context, "sp1")，mysql驱动则需手动执行ROLLBACK TO SAVEPOINT sp1 - savepoint 名字必须唯一，重复定义会导致后续
Release或RollbackTo出错
事务超时后，Commit() 和 Rollback() 都卡住或返回 context deadline
这是最容易被忽略的性能/可靠性盲区：事务未显式设置上下文，数据库侧超时（如 PostgreSQL 的 idle_in_transaction_session_timeout）会单方面 kill 连接，但 Go 侧 tx.Commit() 或 tx.Rollback() 仍会阻塞，直到 TCP 层探测失败（可能长达数分钟）。
解决办法只有一个：所有事务操作必须带 context。
- 开始事务用
db.BeginTx(ctx, nil)，把带 timeout 的 context 传进去 -
Commit()和Rollback()都接收 context 参数（Go 1.21+），超时后立即返回context.DeadlineExceeded - 注意：即使 context 超时，也不代表数据库没执行完；你需要结合应用日志 + 数据库审计日志交叉验证
别省那几行代码——漏掉 context，线上就等着查半夜。
