Go 的 defer 是注册即入栈、退出前逆序弹出的 LIFO 行为；循环中每次 defer 连同当时已求值的参数压栈，故输出逆序；参数在 defer 语句执行时即求值拷贝，非运行时最新值。
Go 的 defer 不是“等函数结束再跑”，而是“注册即入栈，退出前逆序弹出”——这是运行时强制保证的 LIFO 行为，不是优化、不是巧合，写法和执行顺序天然不一致。
defer 在 for 循环里为什么输出逆序？
因为每次执行 defer 语句，Go 运行时就把它连同**此时已求值的参数**一起压入当前函数私有的 defer 栈。循环五次，就压入五个调用，最后那个在栈顶；函数返回前统一从栈顶开始弹出执行。
-
s := []int{1,2,3,4,5}→for i := range s { defer fmt.Println(s[i]) }输出5 4 3 2 1 - 这不是编译器“聪明”，而是每个
defer都真实注册了一次，栈结构决定了必须逆序 - 哪怕循环体里混着
return或panic，只要defer已注册，就一定按这个顺序执行
defer 参数为什么不是“最新值”？
参数在 defer 语句执行到那一行时就完成求值并拷贝——值类型（int、string）拷贝值，指针类型拷贝地址，闭包才读运行时最新状态。
for i := 0; i 全输出 <code>3：因为三次注册都捕获了变量i的地址，执行时i已是循环终值- 想输出
0 1 2，得显式传参：defer func(n int) { fmt.Println(n) }(i) - 若
i是指针，且指向的内容被后续修改，那defer执行时看到的就是修改后的内容
多个 defer 的执行顺序怎么控制？
顺序由 defer 语句出现的**位置**决定，不是代码书写顺序，而是注册顺序；而执行顺序永远是后注册的先执行。
立即学习“go语言免费学习笔记（深入）”；
-
defer f1()写在前面 → 入栈早 → 弹出晚defer f2()写在后面 → 入栈晚 → 弹出早 - 资源释放必须注意依赖关系：子资源要先关，父资源后关；否则可能触发
use of closed network connection - 无法靠“写在下面就后执行”来推断——必须把关键释放逻辑放在靠后的
defer语句上
命名返回值能被 defer 修改，匿名不能
因为 return 分两步：先写返回值到命名变量内存位置，再执行所有 defer，最后真正退出。命名返回值和 defer 操作的是同一块内存。
-
func f() (x int) { defer func() { x++ }(); return 1 }→ 返回2 -
func g() int { x := 1; defer func() { x++ }(); return x }→ 返回1（defer改的是局部变量x，不影响已拷贝的返回副本） - 这个时机差很窄：就在
return赋值之后、函数帧销毁之前，稍不留神就错过
真正难的不是记住 LIFO，而是时刻意识到：参数求值发生在注册瞬间，变量捕获方式决定最终取值，而 defer 栈的生命周期严格绑定函数退出路径——它不关心你写了什么逻辑，只忠实地执行注册时拍下的快照和栈结构。
