defer 执行顺序是 LIFO，因为编译器将 defer 调用压入延迟栈，函数返回前统一出栈执行；这符合资源释放的反序需求，且参数在声明时求值、命名返回值可在 defer 中修改，panic 前也先执行全部 defer。
defer 执行顺序为什么是 LIFO（后进先出）
因为 Go 编译器把每个 defer 调用“压栈”到当前函数的延迟调用栈中，函数即将返回（执行 RET 指令前）时再统一“出栈”执行——栈的天然特性就是后进先出。
这不是设计偏好，而是资源释放逻辑的刚性需求：比如你先 open 文件，再基于它 os.Mkdir，再在目录里 o 一个文件。释放时必须反序：先关文件，再删目录，最后释放父级句柄。LIFO 让你在申请资源的**同一行立刻写 defer**，自然形成安全配对。
s.Create
常见错误：误以为 defer 是“按代码顺序执行”
典型现象是循环中直接写 defer f(i)，结果所有 defer 都捕获了循环末尾的 i 值；或以为多个 defer 会像普通语句一样从上往下跑，实际却是倒着执行。
-
defer的参数在声明时就求值并拷贝（规则一），不是执行时才读变量 - 多个
defer按出现顺序入栈，但出栈顺序相反（规则二） - 哪怕中间有
panic，也先全部按 LIFO 执行完defer，再向上传播 panic
func demo() {
defer fmt.Println("A")
defer fmt.Println("B")
panic("boom")
}
// 输出：
// B
// A
// panic: boom
命名返回值 + defer 修改返回值的陷阱
当函数有命名返回值（如 func foo() (err error)）时，defer 函数能读写这个变量——但仅限于命名返回值，匿名返回值不可见。这是因为命名返回值在函数入口就已声明并分配内存，而 defer 在 return 赋值之后、RET 指令之前执行。
-
return分两步：先赋值给返回变量，再触发defer执行 - 如果
defer匿名函数里修改了命名返回值，会影响最终返回结果 - 但若返回值是结构体或指针，要注意是值拷贝还是地址引用——规则一仍适用
func bad() (x int) {
defer func() { x++ }()
return 5 // 实际返回 6
}
性能和工程实践建议
defer 有轻微开销（函数调用 + 栈帧管理 + 可能的逃逸分析），但在绝大多数业务场景下可忽略。真正要警惕的是滥用：
- 避免在高频循环内直接写
defer（如每轮处理都defer close(ch)），会导致延迟调用栈暴涨甚至 OOM - 应封装为独立函数：
defer cleanup(conn)，并在cleanup内部做判断和关闭 - 调试时可用
runtime.Stack()打印当前 goroutine 的 defer 栈（需开启GODEBUG=deferpcstack=1）
