defer在return赋值后、函数真正返回前执行，遵循LIFO顺序；参数在defer语句执行时立即求值；可修改命名返回值，但不能影响匿名返回值或局部变量。
defer 实际在 return 赋值之后、函数真正返回之前执行
很多人以为 defer 是“函数 return 语句执行完才跑”，但这是错的。Go 中的 return 不是原子操作：它先完成返回值赋值（对有名返回值，就是给那个变量赋值；对匿名返回值，是把表达式结果拷贝进临时返回槽），然后才触发 defer 栈执行，最后才真正退出函数。
这意味着：defer 确实发生在 return 关键字“出现之后”，但不是在“函数已返回”之后——它仍处于函数体内，且能读写有名返回值、调用 recover、修改闭包捕获的变量。
常见错误现象：
- 写
func f() int { x := 1; defer func(){x++}(); return x }，以为返回 2 —— 实际返回 1，因为x是局部变量，defer改的不是返回值本身 - 写
func f() (x int) { x = 1; defer func(){x++}(); return }，返回 2 —— 因为x是有名返回值，defer直接改的就是它
defer 参数在注册时就求值，不是在执行时
这和“defer 最后执行”的直觉冲突最明显：你看到 defer fmt.Println(i)，会下意识觉得它打印的是函数退出时的 i 值，但其实 i 在 defer 那行被执行时就被取值并缓存了。
使用场景：
- 循环中注册
defer：如果写for i := 0; i ，输出是 <code>2 2 2（不是2 1 0），因为所有defer都引用同一个i变量，且每次注册时都取当前值 —— 而循环结束时i == 3，但最后一次迭代后i自增为 3，所以实际输出3 3 3？不，等等：更准确地说，是每次迭代中i的值被立即求值传入fmt.Println，所以若循环体是defer fmt.Println(i)，则三次注册分别传入 0、1、2，但由于 LIFO 执行顺序，输出是2\n1\n0 - 想捕获执行时的值，得用闭包显式捕获：
defer func(v int){ fmt.Println(v) }(i)
panic 时 defer 仍执行，但 recover 必须在 defer 内调用
defer 不是“只在正常 return 时跑”，它在函数因 panic 而终止时也照常执行——这是它能用于错误恢复的前提。但关键限制是：recover() 只有在 defer 函数内部调用才有效；在普通代码里或 panic 后直接写 recover() 没用。
容易踩的坑：
- 把
recover()写在defer外面，比如recover(); defer func(){...}()—— 它根本不会生效 - 在多个
defer中，recover()必须出现在 panic 发生前已注册的某个defer里，且该defer尚未执行完毕（即它必须是栈中“更高位”的那个） -
recover()只能捕获当前 goroutine 的 panic，不能跨 goroutine 传递
多个 defer 按 LIFO 顺序执行，不是按代码书写顺序
写 defer A(); defer B(); defer C()，执行顺序是 C → B → A，不是 A → B → C。这不是 bug，是 Go 明确设计的栈行为：每个 defer 都压入当前函数的 defer 栈，函数退出时从栈顶弹出执行。
为什么这样设计？
- 资源清理更自然：比如先
f, _ := os.Open(...)，再mu.Lock()，接着写defer mu.Unlock()和defer f.Close()，LIFO 让f.Close()先于mu.Unlock()执行，符合“后开先关”逻辑 - 避免依赖断裂：后面注册的
defer往往依赖前面注册的资源状态（如锁、上下文），必须先清理后者 - 循环中注册多个
defer时，执行顺序是倒序迭代 —— 容易误判生命周期，尤其当 defer 里带指针或闭包时
最常被忽略的一点：LIFO 是针对“注册时机”，不是“作用域嵌套”或“缩进层级”。哪怕你在 if 分支里写 defer，在 for 里写 defer，它们全被平权压入同一个栈，仅按注册先后逆序执行。
