defer 仅确保资源清理，不处理错误或捕获 return 值；配合 recover 可捕获同 goroutine 中 panic，但需在 defer 函数内直接调用；命名返回参数才能让 defer 读取即将返回的值；参数在 defer 声明时求值而非执行时。
Go 语言中 defer 本身不处理错误，也不能直接“恢复” panic（它只是延迟执行），但配合 recover 可用于 panic 后的错误捕获；而常见误区是试图用 defer 捕获 return 前的 error 值——它做不到，只能确保资源清理逻辑一定执行。
defer 不会自动获取或传递 error 值
很多人写类似这样的代码，期望 defer 能“看到”函数返回的 err：
func doSomething() error {
f, err := os.Open("file.txt")
if err != nil {
return err
}
defer f.Close() // ✅ 正确：确保关闭
defer func() {
fmt.Println("error is:", err) // ❌ 错误：这里 err 是初始零值，不是 return 时的值
}()
return someOp(f)
}
这是因为 defer 的函数体在声明时就绑定了当前作用域变量的副本（或指针），而 err 在 return 前才被赋新值。真正能访问到返回值的方式只有命名返回参数 + defer 匿名函数内读取：
- 必须使用命名返回参数（如
func() (err error)） -
defer中的匿名函数才能通过变量名读取即将返回的值（Go 规范允许在 defer 中修改命名返回值） - 但这仅适用于“记录日志”“补充错误信息”等场景，不能替代正常错误检查
用 defer + recover 捕获 panic，但仅限顶层或明确边界
recover 必须在 defer 函数中直接调用才有效，且只对同一 goroutine 中的 panic 生效。典型用法：
立即学习“go语言免费学习笔记（深入）”；
func safeRun(fn func()) (err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panic recovered: %v", r)
}
}()
fn()
return nil
}
注意：
-
recover()只在defer函数中且 panic 正在发生时才非 nil；其他时候返回 nil - 不要在每层函数都加
defer/recover，这会掩盖真实问题；应在明确的边界处（如 HTTP handler、goroutine 入口）集中处理 - recover 后的程序可继续运行，但 panic 发生点的栈已销毁，无法“回滚”状态
defer 最可靠用途：资源清理，而非错误流转
文件、锁、数据库连接、临时目录等需要成对操作的资源，defer 是最安全的选择：
-
defer f.Close()比手动if err != nil { f.Close() }更不易遗漏 - 即使函数中间
return多次，defer仍保证执行 - 多个
defer按后进先出（LIFO）顺序执行，适合嵌套资源释放（如先 close body，再 close resp） - 避免在循环中无条件
defer，可能导致资源堆积（如循环打开文件未 close）
真正容易被忽略的是：defer 的函数体在声明时求值其参数，而不是执行时。比如 defer log.Println(time.Now()) 打印的是 defer 声明时刻的时间，不是实际执行时刻——要延迟求值，得写成 defer func() { log.Println(time.Now()) }()。
