事务回滚没生效需检查是否显式调用tx.rollback()；go中sql.tx不会自动回滚，必须手动处理，且commit失败后tx不可再用。
事务回滚没生效？检查 db.Begin() 后是否忘了 tx.Rollback() 调用
Go 的 sql.Tx 不会自动回滚，哪怕测试 panic 或提前 return，也必须显式调用 tx.Rollback()。常见错误是只写了 tx.Commit() 分支，漏掉 defer tx.Rollback() 或错误路径的清理逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有测试中开启事务后，立即加
defer tx.Rollback()，哪怕你“打算”正常提交——先保底清理，再按需tx.Commit() - 避免在 defer 中直接调用
tx.Rollback()而不检查错误：它可能返回"sql: transaction has already been committed or rolled back"，这不是 bug，是预期行为，可忽略 - 如果想验证回滚确实发生，别依赖日志或延迟查库；应在
tx上执行操作后、Rollback()前，用另一个干净连接（db.QueryRow()）查数据——此时应看不到未提交变更
测试数据库总残留数据？用临时 schema 或内存数据库替代共享实例
共用一个 postgresql/mysql 测试库时，不同测试并行跑或中断退出，极易留下脏数据。最稳的方式不是靠回滚，而是让每个测试拥有隔离环境。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 本地开发用
sqlite内存模式："sqlite3://file::memory:?cache=shared"，每次sql.Open()都是全新空库，无需清理 - 用 PostgreSQL 时，为每个测试生成唯一 schema 名（如
"test_" + t.Name()），CREATE SCHEMA+SET search_path，测试结束DROP SCHEMA—— 比清空表更彻底，且不影响其他测试 - 避免在
TestMain里全局TRUNCATE所有表：既慢，又无法解决并发测试冲突；schema 级或内存级隔离才是根本解法
db.Exec("BEGIN") 和 db.Begin() 行为完全不同，别混用
手动发 BEGIN 字符串只是起个语句，不创建 *sql.Tx 对象，后续 db.Query() 仍走默认连接池，事务不成立。Go 的事务控制必须走 db.Begin() 返回的 tx 对象。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用
tx, err := db.Begin()，然后所有操作调tx.Query()/tx.Exec()，而不是db.*() -
db.BeginTx(ctx, &sql.TxOptions{...})才能指定Isolation级别；普通db.Begin()用驱动默认级别（PostgreSQL 是ReadCommitted，MySQL 是RepeatableRead） - 如果测试要验证隔离级别行为（比如幻读），必须显式传
&sql.TxOptions{Isolation: sql.LevelSerializable}，否则你以为在测串行化，实际只是读已提交
测试中调用 tx.Commit() 失败后，别假设事务还活着
tx.Commit() 返回 Error 时，该 tx 对象已失效，再调 tx.Rollback() 会 panic 或返回 “transaction closed”。Go 的 sql.Tx 是一次性对象，成功或失败都不可重用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Commit 失败后，不要尝试 Rollback；此时数据已按 DB 状态决定是否持久化，应用层只需记录错误、返回或重试
- 若需“确保清理”，应在 Commit 前就准备好 rollback 逻辑（比如 defer），并在 Commit 成功后显式取消：用
rollbackFunc := func(){}; defer rollbackFunc(); ... if err == nil { rollbackFunc = func(){} } - 更简单做法：统一用
defer func(){ if r := recover(); r != nil { tx.Rollback() }; }()加上 error 判断，但注意 recover 只捕获 panic，不替代正常 error 处理
事务生命周期短、状态明确，但 Go 不做隐式保障。真正麻烦的从来不是写 rollback，而是忘记它只对未 commit 的 tx 有效，以及误以为数据库连接和事务对象是一回事。