defer 在 return 语句确定返回值后、函数栈销毁前执行；命名返回值可被 defer 修改，非命名则不可；多个 defer 按注册顺序后进先出执行；参数在 defer 语句出现时即求值；需谨慎用于资源清理与 panic 恢复，注意性能开销。
defer 在函数 return 之后才执行，但不是在函数完全退出时
很多人以为 defer 是“函数结束时”才跑，结果发现变量值和预期不符——根本原因是它在 return 语句的“返回值已确定、但函数栈尚未销毁”这个精确时间点执行。比如有命名返回值时，defer 里的闭包能修改它；但用 return 42 这种非命名方式，就改不了。
- 命名返回值函数中，
defer可以读写返回变量（如func() (x int) { x = 1; defer func(){x++}(); return }最终返回 2） - 非命名返回值（
return 1）下，defer拿不到返回值的可寻址引用，改了也白改 - 多个
defer按后进先出（LIFO）顺序执行，和调用位置无关，只和注册顺序有关
defer 调用的函数参数在 defer 语句出现时就求值
这是最常踩的坑：你以为 defer fmt.Println(i) 会打印循环结束后的 i 值，结果全打出最后一个值——因为 i 的值在 defer 那行就被取走了，不是真正执行时才取。
- 想捕获当前值？显式传参或用闭包绑定：
defer func(v int){fmt.Println(v)}(i) - 直接写
defer fmt.Println(i)等价于defer fmt.Println(9)（如果循环最后 i==9） - 对指针或结构体字段做 defer 调用时，同样适用该规则：取的是当时地址/字段值，不是运行时快照
资源清理场景下，defer 必须配对且不能漏掉 recover
用 defer 关文件、解锁、关闭连接很常见，但一旦函数中途 panic，没加 recover 的 defer 仍会执行——这本是优点，但若 defer 本身也 panic（比如重复 close 已关闭的 file），就会覆盖原始 panic，导致问题难定位。
- 对可能 panic 的 cleanup 操作（如
file.Close()），务必检查 error：defer func(){ if err := f.Close(); err != nil { log.Println(err) } }() - 不要在 defer 里裸调
panic，更不要依赖它来“替代错误处理” - goroutine 中启动的 defer，仅在其所属 goroutine 结束时触发，不会跨 goroutine 传播
defer 性能开销在高频小函数里不可忽略
每次 defer 注册都会分配一个 runtime._defer 结构体，并维护链表。在每秒调用百万次的热路径上，这会明显拖慢性能，GC 压力也会升高。
立即学习“go语言免费学习笔记（深入）”；
- 基准测试显示：空函数 + defer 比纯 return 慢 3–5 倍（Go 1.21）
- 循环内写
defer是危险操作，会累积大量待执行延迟调用 - 简单资源管理（如局部 slice 切片、小 map 清空）优先用显式代码，而非 defer
defer 的栈式行为很可靠，但它的时机、参数绑定和开销都藏在语法糖下面。写的时候多问一句：“这个值现在取对了吗？”“这里 panic 了还能 clean 干净吗？”“这个函数真需要 defer 吗？”——比记住规则管用。
