defer按lifo顺序执行，参数在注册时求值，可修改命名返回值，panic时仍执行但os.exit不触发；资源释放须逆序，循环中需显式传参避免闭包陷阱。
Go 里 defer 不是用来“让代码看起来更优雅”的装饰语法，它是资源不泄漏的底线保障——没用对，file.Close() 就可能永远不执行；用错了，return 值会被悄悄改掉，还查不出原因。
defer 参数在注册时就求值，不是执行时
这是最常踩的坑：变量后续被修改，但 defer 语句里看到的还是旧值。
-
defer fmt.Println(x)中的x在defer这行被执行时立刻取值，和之后x = 2无关 - 循环中直接写
defer fmt.Println(i)，所有输出都是循环结束时的i值（比如3） - 想捕获当前迭代值，必须显式传参：
defer func(n int) { fmt.Println(n) }(i) - 若传指针（如
&arr），后续改arr[0]会影响defer内部读取结果
多个 defer 按 LIFO 顺序执行，不是代码书写顺序
你写的顺序是“先注册”，执行顺序是“后注册的先跑”，这点直接影响资源释放的逻辑正确性。
-
defer f.Close()和defer conn.Close()同时存在时，要确保子资源先关、父资源后关（比如先关响应体，再关 HTTP 连接） - 嵌套锁场景：
mu1.Lock()→mu2.Lock()→defer mu2.Unlock()→defer mu1.Unlock()才安全 - 误写成
defer mu1.Unlock()在前，defer mu2.Unlock()在后，会导致解锁顺序错乱、死锁风险
命名返回值可被 defer 修改，但多数情况不该这么干
当函数声明带名字（如 func f() (err error)），defer 匿名函数能读写这个变量——但它会让 return 路径变得隐晦。
-
return nil后，defer func() { err = fmt.Errorf("wrap") }()确实会覆盖返回值 - 这种写法只适合极少数收尾包装场景（如统一加 trace id），绝不该用于主业务逻辑判断
- 普通错误处理请用显式赋值：
err = doSomething(); if err != nil { return err }，别依赖defer改返回值 - 匿名返回值（
func() int）无法被defer访问，这点容易被忽略
panic 时 defer 仍执行，但 os.Exit 不触发 defer
defer 的可靠性有明确边界：它覆盖所有 return 和 panic 路径，但不覆盖进程级退出。
-
panic发生后，当前函数的defer仍按 LIFO 执行，然后 panic 向上冒泡 -
os.Exit(0)是直接终止进程，绕过所有 defer、finally、cleanup 钩子，资源必然泄漏 - 测试中如果用
os.Exit模拟失败，会掩盖defer是否真生效——应改用return或panic验证 - HTTP handler 中常见误用：
if err != nil { http.Error(w, "...", 500); os.Exit(1) }—— 正确做法是 return，让中间件或 defer 自然收尾
真正难的不是记住 LIFO 或参数求值时机，而是判断某段清理逻辑到底该放进 defer、还是该拆成独立函数调用、或者干脆交给 caller 处理——这得看资源生命周期是否严格绑定当前函数作用域。一旦跨 goroutine 或逃逸到全局状态，defer 就失效了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
