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）等字段。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次 defer 都要分配内存：在堆上（Go 1.14+ 对小 defer 做了栈上优化，但仍有开销）
- 高频循环中滥用 defer 会导致 GC 压力上升，例如每轮
for i := 0; i 会堆积百万个 _defer - 无法从 Go 代码中访问或操作该链表：它是 runtime 内部实现，
unsafe或 cgo 强行读取属于未定义行为，版本一升级就崩
defer 的 LIFO 顺序由压栈时机决定，与作用域/分支无关
执行顺序只取决于 defer 语句**被执行的先后顺序**，而不是它们在源码中的位置或是否在 if/for 里。Go 运行时遇到一条 defer 就立刻注册（压栈），函数退出时再倒着弹出执行。
func f() {
defer fmt.Print("A")
if true {
defer fmt.Print("B")
}
for i := 0; i
- if 分支里的 defer，只要分支实际执行了，它就入栈；没进分支，就不注册
- defer 不跨函数生效：在
db.Trans()里写的defer db.Commit()，只在Trans返回时执行，跟调用它的dbStuff()无关 - 多个 defer 的执行时机完全同步：没有“早 defer 先执行”的概念，只有“晚注册先执行”
真正难的不是记住 LIFO，而是意识到 defer 的注册发生在运行时、参数求值发生在注册瞬间、而执行又夹在 return 和函数退出之间——这三个时间点错开，才是绝大多数 bug 的根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
