defer仅延迟执行函数，不捕获错误或自动恢复panic；需显式用recover()配合，且必须检查close()等返回的error，命名返回值在defer中可修改，但非命名返回值不可改。
defer 语句本身不捕获或处理错误
这是最关键的误区：很多人以为 defer 能像 try/catch 那样“兜住” panic 或返回错误。实际上，defer 只是延迟执行函数调用，它不拦截错误、不修改返回值、也不自动恢复 panic——除非你显式配合 recover() 使用。
常见错误现象包括：
- 在
defer中调用可能失败的资源关闭函数（如file.Close()），却忽略其返回的error - 期望
defer func() { return err }()能影响外层函数的返回值，结果毫无作用 - 在
defer里调用log.Fatal()导致程序提前退出，掩盖了原始 panic
defer 关闭资源时必须检查 error 返回值
很多 I/O 操作的关闭方法（如 os.File.Close()、sql.Rows.Close()、http.Response.Body.Close()）会返回 error，而这个 error 往往不可忽略——例如磁盘满、网络中断、连接已断开等场景下，Close() 才真正暴露问题。
正确做法是：在 defer 后立即用命名返回值或额外变量捕获并处理该 error：
立即学习“go语言免费学习笔记（深入）”；
func readFile(filename string) (string, error) {
f, err := os.Open(filename)
if err != nil {
return "", err
}
defer func() {
if closeErr := f.Close(); closeErr != nil && err == nil {
// 只有原始 err 为 nil 时，才把 closeErr 当作函数最终 error
err = closeErr
}
}()
// ... 读取逻辑
return content, nil
}
- 不能写成
defer f.Close()就完事——丢失了 close 的 error - 注意：如果函数已有命名返回值（如上面的
err），defer内部可直接赋值；否则需用额外变量暂存 -
sql.Tx.Commit()和Rollback()同理，必须检查返回 error
用 defer + recover 恢复 panic，但仅限于明确可控的场景
recover() 必须在 defer 函数中直接调用才有效，且只对同一 goroutine 中的 panic 生效。它不是通用错误处理机制，而是应急逃生通道。
典型适用场景：
- HTTP handler 中防止 panic 导致整个服务崩溃（如
http.HandlerFunc内） - 插件系统或用户自定义脚本执行时做隔离
- 测试中模拟 panic 并验证恢复逻辑
反模式示例：
func riskyCalc() int {
defer func() {
if r := recover(); r != nil {
log.Printf("recovered: %v", r)
}
}()
panic("unexpected")
return 42
}
- 这里 recover 成功，但函数仍返回 0（int 零值），调用方无法感知异常
- 不应在普通业务逻辑中用 recover 替代错误返回——这会让控制流隐晦、难以测试
- recover 后建议记录日志 + 显式返回 error，而不是静默吞掉 panic
defer 的执行顺序与返回值“快照”特性容易被误用
defer 函数捕获的是**声明时**的变量值（对非指针/引用类型），且按后进先出（LIFO）顺序执行。这对命名返回值尤其关键：defer 中对命名返回值的修改，会影响最终返回结果。
例如：
func demo() (x int) {
x = 1
defer func() { x++ }()
defer func() { x += 10 }()
return // 实际返回 x = 12（1 + 10 + 1）
}
- 如果返回值未命名（
func() int），则defer中无法修改最终返回值 - 闭包捕获局部变量时，要注意是否是地址引用：修改
*p会影响原值，但修改p（指针本身）不会 - 在 defer 中启动 goroutine 并访问局部变量？大概率踩到变量已被释放的坑——应显式传参
最易被忽略的一点：defer 的性能开销虽小，但在高频循环中滥用（比如每轮都 defer 一个匿名函数）会明显拖慢速度，并增加 GC 压力。真要延迟清理，优先考虑手动管理或 sync.Pool。
