defer 执行顺序为后进先出（LIFO），每次 defer 语句执行时即压栈求值后的参数，返回前从栈顶依次执行；循环中需避免变量捕获陷阱，应通过传参或局部变量固定当轮值。
多个 defer 语句的执行顺序是后进先出（LIFO）
Go 中 defer 不是“注册后等 return 再统一调”，而是每次执行 defer 语句时，就立刻把函数和**当时求值完成的参数**压入当前 goroutine 的 defer 链表栈顶。函数返回前，从栈顶开始逐个弹出执行。
这意味着：写在前面的 defer 会比写在后面的 defer 执行得更晚；循环里每轮都 defer，也会按迭代顺序逆序执行。
-
defer fmt.Println("A")→ 记录 "A"，但参数已求值为字符串字面量 -
defer fmt.Println("B")→ 记录 "B"，压到栈顶，所以先执行 - 最终输出顺序是
B、A
这个规则对嵌套也成立：外层函数的 defer 和内层匿名函数里的 defer 是独立压栈的，各自按 LIFO 执行，不跨作用域混排。
for 循环中写 defer 容易踩变量捕获坑
在循环里直接写 defer func() { fmt.Println(i) }()，几乎总是错的——因为所有 defer 共享同一个变量 i 的地址，等真正执行时，i 已经是循环结束后的终值（比如 3），导致全部打印相同数字。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确做法：用局部变量传参，让每次 defer 捕获的是当轮的值：
defer func(val int) { fmt.Println(val) }(i) - ✅ 或提前赋值：
val := i; defer func() { fmt.Println(val) }() - ❌ 错误写法：
for i := 0; i → 全部输出 <code>3
这种陷阱在资源清理场景尤其危险：比如循环打开多个文件再 defer 关闭，若没做值捕获，可能反复关同一个文件句柄，其余文件泄露。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
命名返回值 + defer 修改返回值要小心副作用
只有函数声明了命名返回参数（如 func() (err error)），defer 中的匿名函数才能读写该变量。但要注意：它不是“拦截 return”，而是直接操作那个内存位置。
- 如果 defer 中修改了命名返回值，会影响最终返回结果，例如：
result = 10; defer func() { result *= 2 }()→ 返回20 - 但 defer 里调用另一个函数（如
someFunc()）并忽略其返回值，不会自动赋给result；必须显式写result = someFunc() - 多个 defer 修改同一命名变量时，按 LIFO 顺序生效，后注册的 defer 先执行、后覆盖
这种写法适合日志补充或错误包装，不适合复杂逻辑分支；一旦函数体中有提前 return，容易漏掉某些 defer 对返回值的修正。
defer 在 panic/recover 场景下只对同 goroutine 有效
recover() 必须在 defer 函数体内直接调用才有效，且仅能捕获当前 goroutine 中正在发生的 panic。它不能跨 goroutine 传播或恢复。
- ✅ 正确模式：
defer func() { if r := recover(); r != nil { /* 处理 */ } }() - ❌ 错误模式：
defer recover()或把 recover 包在另一层函数里间接调用 - panic 发生后，defer 链仍会完整执行，但栈已展开，原 panic 点上下文（如局部变量状态）不可恢复
别在每个小函数都加 defer+recover；应在明确边界处（如 HTTP handler 入口、goroutine 启动点）集中处理，否则会掩盖真实错误位置，且无法回滚已发生的副作用。
真正难调试的，往往是 defer 里依赖了未初始化的变量、或在循环中误用了共享引用——这些不会报错，但行为完全偏离预期。
