defer在函数return或panic前执行，此时返回值已赋值但栈未弹出；参数在defer注册时立即求值，多个defer按lifo顺序执行；命名返回值可被defer修改，匿名返回值不可；资源释放需注意注册顺序与判空。
defer 不是“函数末尾才跑”，而是嵌在 return 或 panic 流程里的固定环节：返回值已赋值、但函数栈还没弹出时执行。
defer 参数在注册时就求值，不是执行时
这是最常误判的点。写 defer fmt.Println(i)，打印的是这一行执行时的 i 值，不是函数退出时的值。
- 错误写法：
for i := 0; i → 全部输出 <code>3 - 正确写法（显式传参）：
for i := 0; i - 或用局部变量绑定：
for i := 0; i -
time.Now()、err.Error()这类表达式也立即求值；想记录实际执行时刻，得写成defer func() { log.Println(time.Now()) }()
多个 defer 按 LIFO 顺序执行，不是代码顺序
它们被压入一个栈，函数退出时从栈顶弹出。这直接影响资源释放是否安全。
-
defer f.Close()必须写在f, _ := os.Open(...)之后，但执行时自动变成“先关文件” - HTTP 客户端中，
defer resp.Body.Close()必须在defer client.Close()之前注册，否则 Body 可能因连接提前关闭而读不到数据 - 循环里注册多个 defer（如批量打开文件），最终执行是逆序迭代——容易导致
close顺序错乱或 panic - 锁嵌套场景：
mu.Lock()后紧跟defer mu.Unlock()是安全的；但若中间又嵌套了另一把锁，需手动调整 defer 注册顺序，否则可能死锁
命名返回值可被 defer 修改，匿名返回值不行
return 分两步：先赋值（命名返回值此时已存在），再触发 defer 链，最后返回。这个细节决定错误包装是否生效。
- 命名返回值：
func f() (err error) { err = errors.New("raw"); defer func() { err = fmt.Errorf("wrap: %w", err) }(); return }→ 真的返回包装后的 error - 匿名返回值：
func f() error { e := errors.New("raw"); defer func() { e = fmt.Errorf("wrap: %w", e) }(); return e }→ 返回原始 error，defer 改的是局部变量e - 指针返回值例外：
func() *int { i := 0; defer func(){i++}(); return &i }中i是栈变量，defer 确实改了它，但返回的指针可能悬空 - 多条 return 路径下，未显式赋值的命名返回值是零值，defer 修改它可能掩盖逻辑错误
nil 资源必须判空再 defer，recover 必须在 defer 内部调用
这两类错误不会报编译错，但运行时直接 panic 或静默失效，极难定位。
-
f, err := os.Open("x"); if err != nil { return err }; defer f.Close()是安全的；漏掉if err != nil判断就defer f.Close()，f为nil会 panic -
sync.Mutex的Unlock()允许对零值调用，但自定义结构体若Unlock()含指针解引用，不判空就 defer 会 crash -
recover()必须在 defer 函数内部调用才有效；在普通函数中调用返回nil
真正麻烦的不是 defer 本身，而是它和变量作用域、返回值生命周期、资源生命周期三者交织在一起时，稍一疏忽就会让清理逻辑失效或覆盖关键状态。写完 defer，别只看语法对不对，要反向推一遍：参数值是不是你想要的那个时刻的？执行顺序会不会让资源提前不可用？返回值有没有被意外改写？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
