defer按注册顺序逆序执行且参数声明时求值，因其底层采用lifo栈机制：每次defer语句执行即压栈，函数返回前从栈顶依次弹出执行；参数在注册时刻完成求值拷贝，故循环中直接使用变量会导致所有defer共享最终值。
defer 不是“写在哪就从哪开始延迟”，而是按注册顺序逆序执行，且参数在声明时就求值——这点不理解，90% 的资源泄漏和逻辑错乱都由此而来。
defer file.Close() 为什么总在 return 之后才执行？
因为 defer 的触发时机绑定在函数返回动作完成前，不是代码行位置。哪怕 return 写在第一行，只要 defer 已注册，它就一定会执行（除非程序被 os.Exit 强制终止或 panic 未 recover）。
- 函数遇到
return时，先计算返回值、复制到栈/寄存器，再逐个执行已注册的defer - 多个
defer按 LIFO（后进先出）顺序执行：最后写的先跑 -
os.Exit会绕过所有defer，而panic不会——这是关键区别
defer 参数在声明时求值，不是执行时
这导致闭包捕获变量值容易出错，尤其在循环中。
for i := 0; i 输出全是 <code>3，因为i在循环结束时为3，而每个defer都引用同一个变量- 正确写法是传参：
defer func(n int) { fmt.Println(n) }(i)或用局部变量ii := i; defer fmt.Println(ii) - 对指针或结构体字段，注意是地址求值，内容仍可变；对基础类型，是值拷贝
defer 在 panic/recover 中的行为
defer 是 panic 传播链上唯一能“插队”执行的机制，但 recover 必须在 defer 函数体内调用才有效。
-
recover()只在defer函数中调用才有意义，外部调用返回nil - panic 发生后，当前 goroutine 的所有已注册
defer仍会按逆序执行，包括含recover的那个 - 如果
recover成功，panic 被截断，函数继续执行到末尾，然后其他defer才运行 - 不要在
defer里做耗时操作（如网络请求），它会拖慢 panic 恢复路径
什么时候不该用 defer？
不是所有清理场景都适合 defer，滥用反而掩盖问题。
- 在 hot path（高频调用路径）中，
defer有微小开销（Go 1.14+ 优化后多数情况栈分配，但仍有函数注册成本），直接调用Close()更快 - 循环内大量
defer会堆积延迟调用，直到函数退出才集中执行，可能造成内存暂留或状态不一致 - 需要精确控制释放时机（比如提前释放锁以避免死锁），就不能依赖 defer 的“函数末尾”语义
- 函数返回值被
defer匿名函数修改时（如defer func() { x++ }()），容易引发隐蔽副作用
最常被忽略的是：defer 的注册本身是即时的，但执行是延迟的；参数求值也是即时的，但函数体是延迟的。这两层“即时 vs 延迟”的分离，是绝大多数 defer 相关 bug 的根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
