在golang中，defer语句延迟执行但参数立即求值，使用指针时可能导致陷阱。1. defer参数为值类型时，拷贝声明时的值，后续修改不影响；2. defer参数为指针时，地址固定但解引用发生在执行时，值可能变化；3. 闭包捕获变量是引用，显式传参是拷贝；4. 循环中使用defer可能导致资源堆积；5. 并发下defer需谨慎避免计数器混乱。应尽量传值、避免循环defer、注意并发控制。
在Golang中，defer语句常用于资源释放、日志记录等操作，它会在函数返回前执行。但如果你使用的是指针类型，并且对defer的参数求值机制理解不深，就很容易掉进“延迟执行的陷阱”。
关键点在于：defer语句会立即对函数参数进行求值，但函数体的执行被推迟。
defer 参数求值时机
当你写这样的代码：
立即学习“go语言免费学习笔记（深入）”；
func example() {
var i int = 1
defer fmt.Println(i)
i++
}输出结果是 1，而不是 2。因为 i 的值在 defer 被声明时就已经确定了。
但如果换成指针：
func example() {
i := 1
defer func(p *int) {
fmt.Println(*p)
}(&i)
i++
}这段代码会输出 2。为什么？因为在 defer 中传入的是指针，虽然参数在当时就被求值（即地址固定），但实际解引用发生在函数真正执行的时候。所以如果在这期间 i 被修改了，那最终打印的就是新值。
这说明了一个问题：对于指针类型的参数，defer调用中的变量不是拷贝值，而是指向原始内存位置。
指针与闭包捕获的差异
你可能会混淆 defer 和闭包的行为。例如：
func example() {
i := 1
defer func() {
fmt.Println(i)
}()
i++
}这个例子输出的是 2，因为闭包捕获的是变量本身（引用捕获）。
而下面这种形式：
func example() {
i := 1
defer func(v int) {
fmt.Println(v)
}(i)
i++
}输出的是 1，因为这里显式地将 i 的当前值作为参数传入，后续修改不影响已传入的值。
区别在于是否显式传递变量 vs. 是否通过参数传值。
实际开发中容易踩坑的地方
一个常见的场景是在循环中使用 defer，尤其是结合指针操作时，很容易出错。
比如：
func processFiles(files []string) {
for _, filename := range files {
file, _ := os.Open(filename)
defer file.Close()
}
}上面这段代码看似没问题，但实际上每次循环都会注册一个新的 defer，所有文件关闭操作会在整个函数结束时才执行。假设文件很多或打开失败未处理，可能导致资源泄漏或 panic。
另一个更隐蔽的问题出现在嵌套结构中：
func example() {
var wg sync.WaitGroup
for i := 0; i < 5; i++ {
wg.Add(1)
go func() {
defer wg.Done()
// do something
}()
}
wg.Wait()
}这个例子看起来没问题，但如果在 goroutine 内部又启动新的 goroutine 并也用了 wg.Done()，那么计数器可能提前归零导致逻辑错误。
如何避免 defer + 指针带来的陷阱？
- 明确 defer 参数的求值时机：参数在 defer 执行时就会被求值，后续修改会影响指针所指向的内容。
- 避免在 defer 中直接使用指针变量，除非你清楚它的生命周期和值的变化。
- 尽量显式传值而非传指针，这样能减少副作用。
- 不要在循环体内滥用 defer，特别是涉及资源管理时，最好手动控制释放时机。
- 在并发环境下谨慎使用 defer，确保不会因多个 goroutine 同时操作造成混乱。
基本上就这些。defer 很方便，但也容易让人忽略细节，特别是在配合指针使用时，稍不注意就可能出现难以排查的问题。
