应分两步处理：先 defer 保证关闭，再显式调用 Close() 检查错误；命名返回值下 defer 修改 err 会覆盖原错误；defer 中 panic 需用匿名函数 + recover 捕获；defer 不适用于 goroutine 或跨函数资源管理。
Defer 关闭文件时错误被忽略怎么办
Go 里 defer 调用 Close() 很常见，但它的返回值（通常是 error）根本没地方接——defer 不会传播错误，直接丢弃。这导致文件写入失败、磁盘满、权限问题等真实错误悄无声息。
正确做法不是放弃 defer，而是分两步：先用 defer 保证关闭，再在函数末尾显式调用一次 Close() 检查错误。
- 只靠
defer f.Close()是危险的，尤其对写操作（如os.Create后写入） - 写文件后必须手动调用
f.Close()并检查返回的error，因为内核缓冲区刷盘可能在此刻失败 -
defer仍保留在开头，防止提前 return 时漏关；手动Close()放在函数出口前
file, err := os.Create("data.txt")
if err != nil {
return err
}
defer file.Close() // 保底关闭
_, err = file.Write([]byte("hello"))
if err != nil {
return err
}
return file.Close() // 关键：这里捕获 flush 和 close 的真实错误
命名返回值和 defer 冲突导致 panic
当函数用了命名返回值（比如 func foo() (err error)），又在 defer 里修改它，行为容易误判——defer 看到的是“当前作用域的变量”，不是最终返回值的快照。
典型陷阱：在 defer 中调用可能失败的 Close()，并试图赋值给命名返回值 err，结果覆盖了前面真正的错误。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 命名返回值在函数入口就初始化（如
err = nil），defer捕获的是这个变量的地址 - 如果主逻辑已设
err = fmt.Errorf("xxx")，而defer又执行err = f.Close()，且Close()返回nil，反而把错误清空了 - 更糟的是，若
Close()返回新错误，它会彻底掩盖原始错误
func badExample() (err error) {
f, err := os.Open("missing.txt")
if err != nil {
return // 此时 err 是 "no such file"
}
defer func() {
err = f.Close() // ❌ 覆盖上面的 err，且 Close() 可能 panic（f 是 *os.File，但 Open 失败时 f == nil）
}()
return
}
用匿名函数 + recover 避免 defer 中 panic 传播
defer 里调用未判空的 Close() 或其他方法，一旦接收者是 nil（比如 os.Open 失败后忘了检查就 defer f.Close()），直接 panic，且无法被外层 recover 捕获——因为 defer 在函数 return 后才执行，此时栈已开始收拢。
安全做法是把可能 panic 的清理逻辑包进匿名函数，并在其中 recover。
- 不要直接
defer f.Close()，尤其当f来源不可靠时 - 改用
defer func() { ... }()结构，在里面加if f != nil判空 +recover() - 注意：
recover()只在defer的匿名函数中有效，放在普通函数里没用
func safeClose(f *os.File) {
defer func() {
if r := recover(); r != nil {
log.Printf("recover from close panic: %v", r)
}
}()
if f != nil {
f.Close() // 即使 panic 也被捕获
}
}
// 使用：
f, err := os.Open("x")
if err != nil {
return err
}
defer safeClose(f)
defer 不适合替代 finally 的资源管理场景
很多人把 defer 当成 Go 的 finally，但它的执行时机和语义有本质区别：它注册在当前函数栈帧，只在该函数 return 后运行；而真正需要“无论是否异常都执行”的逻辑，有时得跨多层函数或涉及 goroutine。
比如启动一个 goroutine 做后台写日志，主线程要确保它结束——这时 defer 完全无效，因为 goroutine 独立运行，函数 return 后它还在跑。
-
defer管不了 goroutine 生命周期，也管不了子进程、网络连接池、第三方 SDK 的内部状态 - 需要明确的生命周期控制时（如
sync.WaitGroup、context.WithCancel），必须手动配对操作 - 数据库
*sql.DB的Close()可以defer，但连接池里的单个*sql.Conn必须显式Close()，否则泄漏
最常被忽略的一点：defer 的执行顺序是后进先出（LIFO），但多个资源之间可能有依赖关系（比如先关子连接，再关父连接池），这时候硬套 defer 容易反序出错。
