defer执行顺序是后进先出，因为Go将每个defer调用压入函数私有栈，返回前按栈的LIFO顺序弹出执行，与代码书写顺序相反，如连续defer输出为third→second→first。
defer 执行顺序为什么是后进先出
因为 Go 运行时把每个 defer 调用压入一个函数私有栈，返回前按栈顺序逐个弹出执行——不是按代码书写顺序，也不是按作用域嵌套深度。
常见错误现象：defer fmt.Println(i) 在循环里闭包了变量，结果全打印最后一个值；你以为它“记住”了每次的 i，其实它只记住了变量地址，而栈上所有 defer 都在函数末尾才执行，那时 i 已经是终值。
- 每个函数有自己的
defer栈，互不干扰 -
defer语句本身在定义时求值（比如函数参数、表达式），但调用延迟到函数 return 前 - 如果函数 panic，
defer仍会执行，且仍遵循 LIFO：最后 defer 的最先跑
多个 defer 在同一函数里怎么排执行顺序
看它们被声明的位置：越晚写的 defer，越早执行。这和调用栈的 push/pop 逻辑完全一致。
func f() {
defer fmt.Println("first")
defer fmt.Println("second")
defer fmt.Println("third")
return
}
输出是：third → second → first。不是靠缩进、不是靠是否在 if 分支里，只看语句在源码中出现的先后。
立即学习“go语言免费学习笔记（深入）”；
- 哪怕
defer写在 if/for 里，只要执行到了那条语句，就入栈 - 如果某个
defer没被执行（比如前面 return 或 panic 跳过了它），就不会入栈，自然也不会执行 - 注意：
defer后面跟的是函数调用表达式，不是函数字面量；写成defer func(){...}()是立即执行，不是延迟
defer 和资源释放之间容易漏掉的关键点
很多人以为写了 defer file.Close() 就万事大吉，但实际释放时机受函数生命周期严格约束——如果函数长期不返回，文件句柄就一直占着。
常见错误现象：http.HandlerFunc 里 defer 关闭 response body，结果 handler 返回后连接还没断，body 又被后续读取导致 panic；或者 defer 关闭数据库连接，但连接池管理器自己另有回收逻辑，双重关闭触发 "use of closed network connection"。
-
defer不等于“自动 GC”，它只是把调用推迟到函数退出那一刻 - 对 io.Reader/io.Writer 类型，defer 关闭前要确认是否已读完或写完，否则可能丢数据或阻塞
- 有些资源（如 goroutine、timer）不能靠 defer 清理，得主动 cancel 或 stop
- 性能影响：大量 defer 会略微增加函数退出开销，不过一般可忽略；但 defer 里做重操作（如 sync.WaitGroup.Wait）可能拖慢 return
defer 在 panic/recover 场景下的行为边界
defer 确实会在 panic 后执行，但它不会“捕获”panic；只有 recover() 能中断 panic 流程。两者配合才有意义。
常见错误现象：写了 defer 但没 recover，panic 仍向上冒泡；或者 recover 写在 defer 外面，根本没机会运行；又或者 defer 里 recover 了，但忘了检查 err 是否非 nil，结果误判为正常流程。
-
recover()只在 defer 函数中调用才有效，在普通函数里调用返回 nil - 同一个函数里多个 defer，recover 只能捕获当前 panic，且仅第一次调用有效；后续再 recover 返回 nil
- 如果 defer 中 panic，会覆盖原有 panic；想保留原 panic，需显式 re-panic
- 注意：defer 的执行顺序不受 panic 影响，仍是 LIFO；但一旦某 defer panic，后面的 defer 就不执行了
最常被忽略的是 defer 的“作用域绑定”——它绑定的是当前函数的退出，不是某段逻辑块的结束。想模拟块级资源管理，得用匿名函数封装 + 显式调用，而不是依赖 defer 自动感知作用域。
