defer语句的参数在注册时求值，不是执行时求值；即defer语句执行到该行时立即捕获参数当前值（传值快照），后续变量修改不影响已注册defer的行为。
defer 不是“延迟调用函数”，而是“注册延迟执行语句”——它在当前函数返回前按后进先出（LIFO）顺序执行，且**捕获的是语句执行时的参数值，不是定义时的变量引用**。这点不理解，90% 的 defer bug 就源于此。
defer 语句的参数在注册时求值还是执行时求值？
在 defer 语句被解析到时，其参数就完成求值（即“传值快照”），而非等到函数真正 return 时再取值。这导致闭包、变量重赋值场景下行为反直觉。
常见错误现象：for i := 0; i 输出三个 <code>3，而非 0 1 2。
原因：三次 defer 注册时，i 都是同一个变量；等循环结束、函数 return 时才执行所有 defer，此时 i == 3。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 需要捕获当前迭代值，显式传参：
defer func(n int) { fmt.Println(n) }(i) - 或用局部变量绑定：
for i := 0; i - 避免在
defer中直接读取可能被修改的外部变量（如循环变量、error 变量等）
defer 调用时机与 panic/recover 的关系
defer 语句一定会在函数返回前执行，无论是否发生 panic。这是实现资源清理和错误恢复的关键机制。
使用场景：文件关闭、锁释放、日志记录、recover 捕获 panic。
注意点：
-
defer在panic后仍会执行，但若defer内部也panic，则原 panic 被覆盖（除非用recover） -
recover()必须在defer函数内部调用才有效；在普通函数中调用返回nil - 多个
defer按注册逆序执行：后注册的先执行，适合嵌套资源释放（如先关子资源，再关父资源）
示例：
func f() {
defer func() {
if r := recover(); r != nil {
log.Printf("recovered: %v", r)
}
}()
panic("boom")
}
defer 对性能的影响有多大？
每次 defer 语句都会在栈上分配一个 _defer 结构体（Go 1.14+ 改为复用链表），并做一次函数地址和参数拷贝。开销比普通函数调用略高，但远低于 goroutine 或系统调用。
性能影响取决于频率：
- 高频循环内（如每轮都
defer unlock()）建议改用显式调用，避免累积开销 - HTTP handler、数据库事务这类“每请求一次”的场景，
defer开销可忽略 - Go 编译器对单个、无参数、非闭包的
defer（如defer mu.Unlock()）做了优化，实际几乎零成本 - 用
go tool compile -S查看汇编，能确认是否触发了deferproc调用
defer 和 return 语句的执行顺序细节
Go 规范定义：return 不是原子操作。它分为三步：1）计算返回值；2）执行所有 defer；3）真正跳转返回。这意味着 defer 可以修改命名返回值。
容易踩的坑：
- 命名返回值 +
defer修改 → 返回值被意外覆盖（如func f() (err error) { defer func() { err = fmt.Errorf("wrapped: %w", err) }() }） - 非命名返回值无法被
defer修改（因为没变量名可写） - 如果
defer中修改了命名返回值，又没return显式值，该修改会生效
所以不要依赖“defer 修改返回值”来封装逻辑，除非你明确需要这种副作用——它会让控制流难以追踪。
最常被忽略的一点：defer 的 LIFO 行为在嵌套函数、多层 panic、跨 goroutine 场景下依然严格成立，但人脑很难线性推演。遇到复杂清理逻辑时，宁可拆成显式 cleanup 函数，也不要堆叠 5 层 defer。
