defer参数在注册时立即求值，而非执行时；值类型拷贝值，指针类型拷贝地址，闭包可读取运行时最新值，循环中需显式传参避免共享变量，多个defer按LIFO顺序执行。
defer 参数在注册时就完成求值
这是最常踩坑的地方：你以为 defer fmt.Println(x) 会在函数退出时读取 x 的最新值，其实不是。参数在执行到那行 defer 语句时就被拷贝固定了。
值类型（int、string、struct）直接复制一份；指针或引用类型（*int、[]byte、map）拷贝的是地址，后续改内容会影响 defer 执行结果。
- 想捕获变量“当时”的值 → 直接写
defer fmt.Println(x) - 想捕获变量“最后”的值 → 改用闭包：
defer func() { fmt.Println(x) }() - 循环中常见错误：
for i := range s { defer fmt.Println(i) }会全输出最后一个i值，应写成defer func(n int) { fmt.Println(n) }(i)
多个 defer 按 LIFO 顺序执行
defer 不是按代码顺序执行，而是压栈后弹出——最后写的最先执行。这决定了资源释放是否合理，比如打开文件和关闭文件的配对。
典型场景是嵌套资源：子连接要先关，主连接后关；数据库事务回滚要早于连接关闭。如果顺序反了，可能触发 “use of closed network connection” 这类错误。
立即学习“go语言免费学习笔记（深入）”；
-
defer f1.Close()和defer f2.Close()注册顺序决定实际调用顺序 - 若需特定顺序（如锁嵌套），必须手动调整
defer语句位置，不能依赖代码书写顺序 - Go 1.22+ 对循环中闭包的
defer行为做了优化，但参数求值时机规则没变
defer 在 return 赋值之后、函数真正退出之前运行
这个“之间”阶段很关键：返回值已经写入栈帧，但函数还没退出。所以命名返回值能被 defer 修改，匿名返回值不能。
看这个函数：func counter() (ret int) { ret = 1; defer func() { ret += 10 }(); return }，最终返回的是 11；但如果是 func() int { r := 1; defer func() { r += 10 }(); return r }，返回仍是 1。
- 命名返回值（
func() (x int)）和返回变量是同一内存位置，defer可修改它 - 匿名返回值（
func() int）在return时已拷贝副本，defer改的是局部变量，不影响返回值 - panic 场景下，
defer同样在这个时机执行，所以recover()必须放在defer函数里才有效
底层是 _defer 结构 + 链表管理
每次调用 defer，运行时会创建一个 _defer 结构体，存函数指针、参数、栈帧信息，并链入当前 goroutine 的 _defer 链表头部。函数退出时遍历链表，逆序执行。
这个结构定义在 runtime2.go 中，字段包括 fn（延迟函数）、sp（注册时栈指针）、pc（程序计数器）和 link（指向下一个 _defer）。堆上分配还是栈上分配由编译器判断，但逻辑上都属于当前栈帧生命周期。
- Go 1.14+ 对
defer性能做了显著优化，小函数、无参数场景几乎零开销 - 大量
defer（如每轮循环都 defer）仍可能触发堆分配，影响 GC 压力 - 调试时看到的
runtime.deferproc和runtime.deferreturn就是这个机制的入口和出口
defer 就会变成隐藏的 bug 发源地。 
