defer 是在 return 前按 LIFO 执行的调用，return 分三步：计算返回值、执行 defer、跳出函数；命名返回值可被 defer 修改，非命名则不可；panic 后 defer 仍执行；闭包捕获变量发生在 defer 定义时。
defer 语句不是“延迟执行函数”，而是“注册一个将在当前函数 return 前按后进先出（LIFO）顺序执行的调用”——这个本质理解错，后续所有行为都容易误判。
defer 的执行时机与 return 的真实关系
很多人以为 defer 在 return 语句“之后”才执行，其实不然：return 不是原子操作。它实际分三步：① 计算返回值（赋值给命名返回值或临时结果）；② 执行所有 defer；③ 跳出函数。这意味着 defer 可以读写命名返回值，也能观察到 panic 的传播路径。
- 命名返回值在 defer 中可被修改：
func f() (x int) { defer func() { x++ }(); return 5 }最终返回 6 - 非命名返回值无法被 defer 修改：
func f() int { defer func() { /* x 不可见 */ }(); return 5 } - panic 发生后，defer 仍会执行（除非程序被 os.Exit 中断）
闭包捕获变量时的常见陷阱
defer 表达式中的变量捕获发生在 defer 语句定义时，而非执行时——但若用匿名函数包裹，且该函数引用了循环变量或后续会变的变量，就极易出错。
- 错误写法（所有 defer 都打印 3）：
for i := 0; i - 正确写法（立即传值）：
for i := 0; i - 或用局部变量绑定：
for i := 0; i
资源释放类 defer 必须检查 error
像 file.Close() 或 rows.Close() 这类操作可能失败，但 defer 不会自动报错或中断流程。忽略其 error 是生产环境常见隐患。
立即学习“go语言免费学习笔记（深入）”；
- 不推荐：
defer file.Close()—— 错误被静默丢弃 - 推荐（配合命名返回值或日志）：
defer func() { if err := file.Close(); err != nil { log.Printf("close failed: %v", err) } }() - 数据库
rows尤其要注意：未 Close 可能导致连接泄漏，且rows.Err()只有在 Close 后才反映扫描是否完整
defer 性能开销与高频场景规避
每次 defer 调用需在栈上分配一个 runtime._defer 结构体，并维护链表。在热点路径（如每毫秒调用数万次的循环内）滥用 defer 会明显增加 GC 压力和延迟。
- 避免在 tight loop 中 defer：
for _, v := range data { defer process(v) }→ 改为显式收尾 - 函数调用频次低（如 HTTP handler、CLI 命令入口）时，defer 的开销可忽略
- go tool compile -gcflags="-m" 可查看编译器是否将 defer 内联或优化掉
最易被忽略的一点：defer 注册的是“调用动作”，不是“函数值”——所以 defer f(x) 立即求值 x，但真正调用 f 是在 return 前。这个求值时序混在闭包、指针、接口转换里，很容易引发意料外的 panic 或竞态。
