不能只靠 defer 做资源清理，因其执行时机滞后、顺序固定且无法在错误路径提前释放资源；应使用匿名函数封装获取与清理逻辑，支持显式调用、panic兜底及跨函数传递。
为什么不能只靠 defer 做资源清理？
因为 defer 在函数返回时才执行，无法控制清理时机；多个 defer 的调用顺序是栈式（后进先出），容易和业务逻辑脱节；更关键的是——它无法在错误路径上提前释放资源，比如打开文件后立即校验失败，你不想等函数结束才关文件。
用匿名函数封装“获取+清理”成原子操作
核心思路是把资源获取和对应的清理逻辑打包进一个闭包，返回的不是裸资源，而是一个带清理能力的对象。常见模式是返回一个结构体或函数对，例如：
func openFileWithCleanup(path string) (io.ReadCloser, func() error) {
f, err := os.Open(path)
if err != nil {
return nil, func() error { return nil }
}
return f, func() error { return f.Close() }
}
调用方拿到 f 和 cleanup 后，可以按需调用 cleanup()，不受函数作用域限制。
- 清理函数必须捕获外部变量（如
f），否则闭包内拿不到引用 - 如果资源可能为
nil（比如打开失败），清理函数应做空判断，避免 panic - 不要在匿名函数里再 defer 清理逻辑——这又绕回原问题
配合 recover 实现 panic 时的强制清理
当资源生命周期跨越多层调用、且可能被 panic 中断时，仅靠调用方手动 cleanup 不可靠。这时可在匿名函数外层加 recover 捕获：
立即学习“go语言免费学习笔记（深入）”；
func withDBTransaction(db *sql.DB, fn func(*sql.Tx) error) error {
tx, err := db.Begin()
if err != nil {
return err
}
// 清理函数捕获 tx，供 panic 时调用
cleanup := func() { tx.Rollback() }
defer func() {
if r := recover(); r != nil {
cleanup()
panic(r)
}
}()
if err := fn(tx); err != nil {
return tx.Rollback()
}
return tx.Commit()
}
注意：这里 cleanup 是普通匿名函数，不是 defer；recover 只负责兜底，正常流程仍由业务代码显式调用 tx.Commit() 或 tx.Rollback() 控制。
-
recover必须放在 defer 函数内，且 defer 要在资源创建后立即注册 - 不要在 cleanup 里再调用可能 panic 的操作（如二次 close）
- 该模式不适用于 goroutine 内部的资源——recover 无法跨协程生效
对比 defer 和匿名函数清理的适用边界
defer 适合单一函数内、短生命周期、无分支决策的资源管理（比如函数开头打开文件，结尾统一关闭）。匿名函数 + 显式 cleanup 更适合：
- 资源需要跨函数传递（如传给回调、注入到 struct 字段）
- 清理条件复杂（比如仅当状态为 “dirty” 才 flush）
- 需要测试资源是否已被清理（可将 cleanup 设为幂等，返回 bool 表示是否真正释放）
- 资源生命周期由外部控制（如连接池中借出/归还）
真正难处理的是那些既需要 early-exit 支持、又得应对 panic、还得支持多次复用的资源——这时候往往得组合匿名函数、接口抽象（如 Closer）、甚至 context 取消机制，而不是幻想一个银弹方案。
