Go defer 参数为什么在登记时就完成求值

代码评审里常见一个迷惑现象：defer fmt.Println(i) 打印的不是函数返回前的最新 i，但 defer func() { fmt.Println(i) }() 却可能读到新值。答案是，defer 登记时就会求出函数值和参数；只有函数调用本身被推迟。匿名函数则把变量读取动作放进了稍后执行的函数体。

记住一句话：普通参数是登记时的快照，闭包变量是执行时读取；命名返回值会先被 return 赋值，再交给 defer 修改。

一、参数为什么停在 defer 登记时

在批量处理请求时，如果用 defer 记录退出状态，下面两种写法的含义完全不同：

func snapshot() {
	state := "start"
	defer fmt.Println(state) // 参数在登记时求值，保存 start
	state = "done"
}

func liveRead() {
	state := "start"
	defer func() {
		fmt.Println(state) // 函数体稍后执行，此时读取 done
	}()
	state = "done"
}

snapshot 打印 start，liveRead 打印 done。第一段把 state 作为 Println 的参数传入，第二段只登记一个匿名函数，真正的变量读取藏在函数体里。规范把这两步分开：函数值和参数先按普通调用规则求值，调用则保存到函数返回前。

二、闭包捕获的不是一份自动复制的结果

闭包示例容易被误解成“defer 会重新求值”。其实变化来自匿名函数：它引用外层变量，变量的读取表达式等到匿名函数执行才发生。把日志、指标或清理动作写成闭包时，要明确你需要的是登记时快照，还是退出时状态。

循环里尤其要谨慎。大量 defer 会积压到当前函数返回才执行，资源可能比预期活得久；如果每一轮都要及时关闭文件或结果集，应把单轮逻辑放进小函数，让 defer 的生命周期跟着小函数结束，而不是把它堆到整个批处理函数末尾。

三、命名返回值为什么能被 defer 改掉

return 1 并不是立刻跳出函数。对命名返回值来说，返回表达式会先写入结果参数，然后执行 defer，最后才把结果交给调用方：

func normalize() (n int) {
	defer func() {
		if n 

因此 normalize 返回 0。这类写法适合统一补充错误、埋点或收尾状态，但也会增加控制流的隐藏层。团队代码中如果 defer 改写返回值，最好让命名结果保持短小，并在函数注释或附近代码说明这个约定。

四、把 defer 放在正确的生命周期边界

资源型代码仍然推荐“成功打开后立即 defer 关闭”，因为函数中途有多个 return 时更不容易漏清理。代价是 defer 的执行点固定在当前函数返回前，所以高频循环不要把每轮资源都登记在外层函数；拆成单轮函数通常更清楚。

常见问题

defer 的参数会不会等函数结束才计算？

不会。参数在执行 defer 语句时求值，结束时只执行已经保存的调用。

为什么匿名函数能看到变量的新值？

因为读取变量的表达式位于匿名函数体内，读取时机是 defer 真正执行时。

defer 一定比 return 晚吗？

它比 return 表达式写入结果晚，但比函数真正返回给调用方早；命名返回值就在这个窗口内可被修改。