defer的核心作用是注册必执行的收尾动作，函数返回前（含panic）按LIFO顺序自动触发；参数在注册时求值，非调用时；需注意nil检查、指针传递、命名返回值修改及性能风险。
defer 的核心作用不是“延迟执行”，而是“注册一个必执行的收尾动作”——它在函数返回前（包括 panic）自动触发，且按后进先出（LIFO）顺序执行。用错时机或误解参数求值，轻则逻辑错乱，重则 nil pointer dereference 或资源泄漏。
defer 参数在注册时就求值，不是调用时
这是最常踩的坑：你以为 defer 会“记住变量”，其实它只“记住当时的值”。
func example() {
i := 10
defer fmt.Println(i) // ← 此刻 i=10，已固定
i = 20
fmt.Println("done")
}
输出是 done 然后 10，不是 20。
- 若需捕获最终值，改用闭包：
defer func() { fmt.Println(i) }() - 若变量可能为
nil（如未成功打开的*os.File），必须先检查错误再defer，否则直接 panic - 对指针或结构体字段，
defer拿到的是副本值；想反映变化，得传指针或闭包
多个 defer 按 LIFO 执行，适合成对资源管理
比如开文件 → 开数据库事务 → 加锁，关闭顺序必须严格相反，否则可能报错或死锁。
立即学习“go语言免费学习笔记（深入）”；
file, _ := os.Open("a.txt")
defer file.Close() // 最后执行
db, _ := sql.Open(...)
tx, _ := db.Begin()
defer tx.Rollback() // 中间执行（若未 Commit）
mu.Lock()
defer mu.Unlock() // 最先执行
- 执行顺序：最后写的
defer最先运行（Unlock→Rollback→Close） - 不要把多个资源清理塞进一个
defer函数里——失去顺序控制，也难调试 - 事务场景中，
defer tx.Rollback()是安全的：即使已Commit，多数驱动会静默忽略
defer 可修改命名返回值，但要小心副作用
当函数声明了命名返回参数（如 func f() (err error)），defer 匿名函数能读写该变量。
func double() (result int) {
defer func() { result *= 2 }()
return 3
} // 返回 6，不是 3
- 这特性可用于统一错误包装、日志补全等，但别滥用——会让返回逻辑变得隐晦
- 若
defer中发生 panic，它会覆盖原函数的 panic；想透传错误，应避免在 defer 里 panic - 不推荐依赖此机制做核心业务逻辑，优先用显式赋值 +
return
defer 不是万能的：循环、高频调用和性能敏感路径要警惕
defer 本质是向函数栈压入一个延迟调用记录，有轻微开销。在以下场景需谨慎：
- for 循环内写
defer→ 可能堆积数百个待执行函数，引发栈膨胀甚至 OOM - 微秒级性能关键路径（如网络包解析循环）→ defer 的注册成本可能显著
- goroutine 泄漏风险：若 defer 调用了带阻塞操作（如 channel send/receive）且未设超时，可能卡住整个 goroutine
- 替代方案：手动
Close()+if err != nil { return err }组合更可控
真正关键的不是“要不要用 defer”，而是“是否在正确的作用域里用”——它绑定的是函数，不是代码块，也不是循环体。
