defer参数在声明（遇到）时立即求值，而非执行时；例如defer fmt.Println(x)中x值当场锁定，后续修改无效，需用闭包或显式传参实现延迟求值。
defer 中的参数在声明时就求值，不是执行时
Go 的 defer 语句会在函数返回前按后进先出顺序执行，但它的参数在 defer 语句被**执行到（即遇到）时立刻求值**，而不是等到真正调用被延迟函数时才求值。这是绝大多数人踩坑的根源。
比如：
func example() {
x := 1
defer fmt.Println("x =", x) // 这里 x 被立即求值为 1
x = 2
}
输出是 x = 1，不是 x = 2。因为 x 在 defer 那行就被读取并拷贝了。
用匿名函数包裹来延迟求值
最直接、最通用的解法是把要延迟执行的逻辑包进一个闭包，让变量捕获发生在真正调用时：
- 把
defer fmt.Println(x)改成defer func() { fmt.Println(x) }() - 注意末尾的
()—— 这是立即调用该匿名函数，而函数体内的x是在 defer 实际运行时才读取 - 如果需要传参，推荐显式传入，避免闭包捕获外部变量带来的歧义：
defer func(val int) {
fmt.Println("x =", val)
}(x)
这样既清晰又安全：参数 x 在 defer 语句执行时求值并传入，但打印动作延迟发生。
注意指针或结构体字段的“假延迟”陷阱
即使你用了闭包，如果 defer 中操作的是指针或可变结构体字段，仍可能得到意外结果：
-
defer func() { fmt.Println(*ptr) }()—— 看似延迟，但解引用的是当前指向的值；如果*ptr后续被改写，打印的就是新值 -
defer func(s *struct{ v int }) { fmt.Println(s.v) }(s)—— 如果s.v后续被修改，且你期望打印旧值，那就错了 - 此时必须在 defer 声明时就做快照：
v := s.v; defer func() { fmt.Println(v) }()
本质上，闭包只解决“读取时机”问题，不解决“值快照”问题。是否需要快照，取决于业务逻辑对“那一刻状态”的要求。
性能与可读性权衡：什么情况真得用闭包？
不是所有 defer 都需要闭包。只有当被 defer 的函数依赖的变量在 defer 之后还会被修改时，才需要干预求值时机：
- 常见场景：资源 cleanup（
os.File.Close()不需要闭包，因为文件句柄本身不变） - 反例：记录耗时
start := time.Now(); defer log.Printf("took %v", time.Since(start))—— 必须用闭包，否则time.Since(start)在 defer 声明时就算完了 - 更安全写法：
defer func(t time.Time) { log.Printf("took %v", time.Since(t)) }(time.Now())
闭包有极小开销（分配函数对象），但在绝大多数业务代码里可以忽略。比起修复因求值时机错误导致的隐蔽 bug，这点成本完全值得。
最易被忽略的是：你以为 defer 里的表达式会“活到函数结束”，其实它只活到那条 defer 语句执行完 —— 变量值、指针目标、甚至 channel 接收结果，都得按这个时间点去判断是否需要快照。
