go事务不会自动回滚，必须显式调用tx.rollback()或tx.commit()，否则事务持续挂起导致锁表、阻塞查询；推荐用defer+committed标志位精准控制回滚，避免重复回滚报错。
Go 的事务不会自动回滚，必须显式调用 tx.Rollback()
哪怕函数 panic、提前 return、或者数据库连接断开，只要没调 tx.Rollback() 或 tx.Commit()，事务就一直挂着——锁表、阻塞其他查询、拖慢整个连接池。这不是 bug，是 Go 的设计选择：你得亲手关灯。
- 常见错误现象：
sql: transaction has already been committed or rolled back，多因 defer 里无条件tx.Rollback()，但前面已成功tx.Commit() - panic 后 recover 了？必须手动
tx.Rollback()，且不能再tx.Commit() - 所有错误路径（包括中间
return err）都不应自己调tx.Rollback()，交给 defer 统一兜底更安全 - 推荐做法：定义
committed := false标志位，在tx.Commit()成功后设为true，defer 中只在!committed时回滚
用 defer + 标志位写回滚，比“先 defer rollback 再 commit”更稳
直接 defer tx.Rollback() 看似简单，但一旦 tx.Commit() 成功，defer 还会再跑一次，触发上面那个报错；而用标志位能精准控制，逻辑也更可读。
- 示例关键结构：
tx, err := db.Begin()
if err != nil { return err }
committed := false
defer func() {
if !committed {
tx.Rollback() // 忽略其返回 error，只关心是否执行了回滚
}
}()
// ... 执行业务 SQL
if err := tx.Commit(); err != nil {
return err
}
committed = true
tx.Rollback() 本身可能返回 error（比如网络中断），但这不表示回滚失败——数据库通常已执行，只是客户端没收到确认；记录日志即可，不要 return err 向上传递tx.Rollback() 的 error 并 panic，也不该用它判断事务状态
context.Context 超时不会终止事务，必须手动响应 ctx.Done()
db.BeginTx(ctx, ...) 中的 ctx 只控制“开启事务”这一步是否超时，后续所有 tx.Query()、tx.Exec() 都不受影响。超时后若不处理，事务照常开着，Commit 还可能成功写入脏数据。
- 正确做法：在 Commit 前加
if ctx.Err() != nil { return ctx.Err() }，或在 defer 中检查ctx.Err() != nil后回滚 - 更稳妥方案：BeginTx 后立刻起 goroutine 监听
ctx.Done()，触发时调tx.Rollback()（sql.Tx内部有状态保护，重复调用安全） -
tx.QueryContext()虽能响应超时并返回context.DeadlineExceeded，但它只中断当前语句，**不结束事务** - 如果事务中要调 HTTP 或 RPC，它们也必须共用同一个
ctx，否则超时逻辑就断了
测试中事务清理不能靠“运气”，要用内存库或独立 schema 隔离
测试里只靠 tx.Rollback() 不保险：测试 panic、中断退出、并发运行都可能导致事务残留或数据污染。真正干净的测试环境，得从隔离机制入手。
- 本地开发首选
sqlite3://file::memory:?cache=shared：每次sql.Open()都是全新空库，不用清表、不担心冲突 - PostgreSQL 测试可用动态 schema：
CREATE SCHEMA test_XXX+SET search_path，测试完DROP SCHEMA，彻底隔离 - 避免在
TestMain里全局TRUNCATE表：慢、不可靠、无法解决并发测试竞争 - 别混用
db.Exec("BEGIN")和db.Begin()：db.Exec("BEGIN")不返回*sql.Tx，后续db.Query()仍走普通连接池，事务根本没成立
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
