Go 中 defer 执行顺序为 LIFO（后进先出），因其将调用压入栈，函数返回时倒序弹出执行；参数在 defer 注册时即求值固化；可修改命名返回值；高频使用有内存开销；资源清理应优先放在入口而非循环内。
Go 里的 defer 不是“写在哪，就在哪执行”，而是注册进一个栈，函数退出前统一倒序执行——这个反直觉点一旦错判，file.Close() 可能比 resp.Body.Close() 先跑，连接就提前断了。
defer 执行顺序为什么是 LIFO？不是代码从上到下
每条 defer 语句执行时，Go 运行时会把函数调用（含当时已求值的参数）压入当前函数的 defer 栈。函数返回前，栈顶元素先弹出执行，所以后写的 defer 反而先跑。
-
defer fmt.Print("A")→ 压栈第 1 个节点 -
defer fmt.Print("B")→ 压栈第 2 个节点（栈顶） - 函数 return → 先弹出 B，再弹出 A
这个行为跟 if、for 无关：哪怕 defer 写在 if true { ... } 里，它照样入栈；循环里多次 defer，每次都会新增一个栈帧。
参数在 defer 注册时就固化，不是执行时读
这是最常踩的坑：defer fmt.Println(x) 中的 x 在这行代码执行那一刻就被读取并拷贝，后续改 x 没用。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误写法：
for _, f := range files { defer os.Remove(f) }→ 所有defer都删最后一个f - 正确写法：
for _, f := range files { f := f; defer func() { os.Remove(f) }() }（显式捕获变量） - 或更简洁：
for _, f := range files { defer func(name string) { os.Remove(name) }(f) }
注意：闭包里不加 f := f 或参数传值，f 是循环变量的地址引用，所有 defer 共享同一个内存位置。
defer 能修改命名返回值，但仅限于有名字的返回参数
只有函数声明带命名返回参数（如 func do() (err error)），defer 里的赋值才能真正影响最终返回值。
-
func f() int { x := 10; defer func() { x = 20 }(); return x }→ 返回 10（x是局部变量，不是返回值） -
func f() (x int) { x = 10; defer func() { x = 20 }(); return }→ 返回 20（x是命名返回参数，defer 可改）
这种机制常用于统一错误包装或日志记录，但别滥用——可读性会下降，且容易和显式 return 冲突。
高频 defer 的内存开销容易被忽略
每次 defer 都要分配一个 _defer 结构体（Go 1.14+ 对小 defer 做了栈上优化，但非绝对）。万级循环里每轮都 defer，GC 压力会明显上升。
- 资源清理场景：优先把
defer放在函数入口附近，而不是循环体内 - 替代方案：手动
close()+recover()包裹关键段，比无节制 defer 更可控 - HTTP 客户端常见误用：
for range reqs { resp, _ := client.Do(req); defer resp.Body.Close() }→ 错，应改为resp.Body.Close()紧跟Do()后立即调用
真正难的不是记住“后进先出”，而是判断哪些操作必须靠 defer 保底，哪些其实该由业务逻辑主动控制——比如数据库事务 rollback，通常得在 if err != nil 分支里显式做，而不是全扔给 defer。
