defer 参数在语句执行时立即求值而非调用时，导致循环中输出旧值、命名返回值可被修改、并发下产生意外快照；应使用闭包捕获最新值，注意LIFO执行顺序及性能开销。
defer 语句中的函数参数在 defer 执行时不会重新求值，而是在 defer 语句出现时就完成求值——这是 go 中最常被误用的机制之一。
defer 后面的函数调用参数立即求值
Go 规范明确要求：defer 后面的函数调用表达式（包括所有参数）会在 defer 语句执行时立刻求值，而不是等到实际调用时。这意味着即使参数是变量，它取的也是当时那一刻的值，和后续变量变化无关。
常见错误现象：
- 期望
defer fmt.Println(i)输出循环结束后的最终值，结果输出全是初始值或上一轮的旧值 - 在
defer中传入指针或结构体字段，误以为能“捕获”未来状态
实操建议：
- 若需延迟访问变量最新值，显式传入闭包：
defer func() { fmt.Println(i) }() - 避免直接传参，改用匿名函数包裹逻辑，确保读取时机可控
- 对基础类型（如
int、string）尤其要警惕——它们是值拷贝，不会随原变量变
defer 在 return 之前执行，但 return 语句本身有隐式赋值
当函数使用命名返回值时，return 语句会先给返回变量赋值，再触发 defer，此时 defer 函数能看到并修改这些命名返回值。
使用场景：
- 统一记录返回值、做日志审计、恢复 panic
- 需要根据函数实际返回结果做清理或修正（例如把空错误转为默认错误）
容易踩的坑：
- 在
defer中修改命名返回值，却没意识到它会影响最终返回结果 - 误以为
defer总是“看不到” return 的值，其实它能看到且能改
示例：
func f() (err error) {
defer func() {
if err == nil {
err = fmt.Errorf("default error")
}
}()
return nil // 最终返回的是 "default error"
}
多个 defer 的执行顺序与栈行为
defer 是后进先出（LIFO）栈式执行，这点和调用栈一致，但容易因嵌套或循环产生理解偏差。
性能影响：
- 每个
defer都有轻微开销（注册、栈帧管理），高频路径慎用过多defer - 编译器对简单
defer有一定优化（如内联、去栈化），但带闭包或复杂参数的无法优化
实操建议：
- 避免在循环中写
defer（除非明确需要每轮都延迟执行） - 调试时可用
runtime.Stack查看实际 defer 调用栈，确认执行顺序 - 用
go tool compile -S观察编译器是否将 defer 内联（搜索CALL runtime.deferproc）
最易被忽略的一点：defer 的参数求值发生在语句执行点，而非函数入口或 return 点——哪怕 defer 写在函数第一行，它看到的也是那一时刻的变量快照，不是“将来某个时间点的状态”。这个“快照”特性在并发、循环、命名返回值等上下文中会反复制造意外。
