defer 在函数退出前统一执行，而非 return 后；return 实为赋值→执行 defer→跳出三步；命名返回值可被 defer 修改，匿名返回值不可；panic 也会触发 defer；defer 参数注册时求值；闭包 defer 易出错，应显式传参；\_defer 是 runtime 栈帧节点，挂于 goroutine 链表。

defer 的注册和执行不是“延迟到 return 后”，而是“在函数退出前统一触发”

很多人误以为 return 是一个原子动作，执行完它函数就结束了。实际上，Go 中的 return 是三步走：赋值返回值 → 执行所有 defer → 跳出函数。这意味着即使你写了 return 42，defer 仍能读取甚至修改命名返回值（如 func() (res int)），但对匿名返回值无效。

• 命名返回值可被 defer 修改：因为它的内存位置在函数栈帧中已固定，defer 可直接写入
• 匿名返回值不可被修改：return 42 会先将 42 搬进返回寄存器/栈槽，defer 再怎么改变量也影响不到它
• panic 也会触发 defer：只要没被当前函数 recover，defer 照常执行；外层函数的 defer 看不到内层 panic

defer 参数在注册时求值，不是执行时 —— 闭包陷阱最常见

写 defer fmt.Println(i) 时，i 的值在 defer 语句执行那一刻就被拷贝并固化了，后续 i 怎么变都无关。而用闭包 defer func(){ fmt.Println(i) }()，则捕获的是变量 i 的地址，最终输出全是循环结束后的值（比如 3, 3, 3）。

• 安全做法：显式传参，如 defer func(v int){ fmt.Println(v) }(i)
• 循环中慎用闭包 defer：尤其 for i := range xs { defer func(){ ... }

  

  () } 几乎总是错的
• 参数求值 ≠ 函数调用：defer f(x, y) 中 x 和 y 立即求值，但 f 本身不执行

_defer 结构体是 runtime 层真实存在的栈帧节点

Go 编译器会把每个 defer 语句编译成对 runtime.deferproc 的调用，并构造一个 _defer 结构体，挂到当前 goroutine 的 defer 链表上（本质是单向链表，但按 LIFO 顺序遍历）。这个结构体里存着：fn（函数指针）、pc（返回地址）、sp（栈指针）、link（指向下一个 _defer）等字段。

• 每次 defer 都要分配内存：在堆上（Go 1.14+ 对小 defer 做了栈上优化，但仍有开销）
• 高频循环中滥用 defer 会导致 GC 压力上升，例如每轮 for i := 0; i 会堆积百万个 _defer
• 无法从 Go 代码中访问或操作该链表：它是 runtime 内部实现，unsafe 或 cgo 强行读取属于未定义行为，版本一升级就崩

defer 的 LIFO 顺序由压栈时机决定，与作用域/分支无关

执行顺序只取决于 defer 语句**被执行的先后顺序**，而不是它们在源码中的位置或是否在 if/for 里。Go 运行时遇到一条 defer 就立刻注册（压栈），函数退出时再倒着弹出执行。

立即学习“go语言免费学习笔记（深入）”；

func f() {
    defer fmt.Print("A")
    if true {
        defer fmt.Print("B")
    }
    for i := 0; i < 2; i++ {
        defer fmt.Print("C")
    }
}
// 输出一定是：CCBA —— 因为两个 C 最后注册，最先执行；B 在 A 之后注册，所以 B 在 A 前执行

• if 分支里的 defer，只要分支实际执行了，它就入栈；没进分支，就不注册
• defer 不跨函数生效：在 db.Trans() 里写的 defer db.Commit()，只在 Trans 返回时执行，跟调用它的 dbStuff() 无关
• 多个 defer 的执行时机完全同步：没有“早 defer 先执行”的概念，只有“晚注册先执行”