defer本身不支持事务控制，必须配合显式状态管理；它不感知panic或业务成败，直接defer tx.Rollback()会导致已提交事务被重复回滚，正确做法是用命名返回值+闭包defer检查结果变量决定Commit或Rollback。
defer 本身不支持事务控制，必须配合显式状态管理
Go 的 defer 只是函数退出时执行的延迟调用，它**不会感知 panic 是否发生、也不知悉业务逻辑是否成功**。直接写 defer tx.Rollback() 会导致事务必然回滚，哪怕你已经 tx.Commit() 成功了。真正起作用的是“在函数末尾根据执行结果决定调用哪个函数”，defer 只是帮你把“收尾动作”推迟到合适时机，而不是自动做决策。
常见错误现象：panic: sql: transaction has already been committed or rolled back，就是因为在 Commit() 后又触发了 defer tx.Rollback()。
- 必须用一个布尔变量（如
committed）标记事务是否已提交 -
defer函数里要检查该标记，仅当未提交才调用Rollback() - 不能依赖
recover()捕获 panic 来判断——因为有些错误（如逻辑校验失败）不触发 panic，但也要回滚
标准模式：用闭包 defer + 命名返回值控制回滚时机
最稳妥的做法是把事务对象和提交状态一起封装进 defer 闭包，并利用命名返回值确保状态可被修改。这样既避免重复调用，又覆盖 panic 和显式 return 两种退出路径。
func doSomething(db *sql.DB) error {
tx, err := db.Begin()
if err != nil {
return err
}
// 命名返回值，用于在 defer 中读取
var result error
// 注意：这里 defer 引用了 result 变量，不是它的值
defer func() {
if result != nil {
tx.Rollback()
} else {
tx.Commit()
}
}()
<pre class="brush:php;toolbar:false;">// 执行业务逻辑
if _, err := tx.Exec("INSERT INTO users(name) VALUES(?)", "alice"); err != nil {
result = err
return result // 不 panic，靠 result 控制 defer 行为
}
if _, err := tx.Exec("UPDATE accounts SET balance = balance - 100 WHERE id = ?", 1); err != nil {
result = err
return result
}
return nil // result 保持 nil，defer 会 Commit}
关键点：
- 使用命名返回值
result error，让 defer 闭包能观察到最终返回值 - 所有错误都赋值给
result并return result，不直接 return 错误字面量 - 不要在 defer 里调用
recover()——它只捕获当前 goroutine 的 panic，且掩盖了本该暴露的错误路径
嵌套事务或多个资源时，defer 链容易失控
当你需要同时管理数据库事务、文件句柄、HTTP 连接等多类资源时，单层 defer 很难清晰表达“哪个资源该在什么条件下释放”。比如文件写入失败要回滚 DB，但 DB 提交失败又不该关闭文件句柄——这时 defer 的执行顺序（LIFO）和无条件触发特性反而增加复杂度。
实际建议：
- 对每个资源单独封装 cleanup 逻辑，例如
defer closeFile(&f)，但closeFile内部要检查f是否为 nil 或已关闭 - 数据库事务仍按前一节方式用命名返回值控制，其他资源的 defer 放在事务 defer 之后（保证事务结束后再清理）
- 避免写
defer func(){...}()嵌套——它难以调试，且闭包捕获变量易出错 - 考虑用结构体封装事务上下文，例如
type TxContext struct { tx *sql.Tx; committed bool }，提供Done(err error)方法统一处理
测试中 mock defer 行为容易漏掉 panic 路径
单元测试时如果只覆盖正常返回和显式 error 返回，但没触发 panic（比如空指针解引用），就可能让 defer 中的 Rollback() 没被执行，导致测试通过但线上出问题。
验证要点：
- 写一个测试用例，显式
panic("test")在事务逻辑中间，确认是否进入Rollback() - 检查日志或 SQL mock 是否记录了
ROLLBACK而非COMMIT - 若使用
testify/assert，可用assert.Panics配合观察副作用 - 注意：Go 1.22+ 的
testing.T.Cleanup()不替代 defer，它只在测试函数返回后运行，无法干预事务流程
真正麻烦的从来不是 defer 怎么写，而是你怎么定义“事务成功”的边界——是 SQL 执行完？还是业务校验通过？还是下游 API 调用也完成？这些状态必须显式传递，defer 只负责最后那一锤子。
