Go defer 捕获变量为什么输出最后一个值

我第一次遇到这个现象，是在函数退出前用 defer 记录一组循环变量：明明循环经过了多个值，日志却像只记住了最后一次。真正的原因通常不是 defer “把值改掉了”，而是要先分清两种写法：普通调用参数在注册时求值，匿名函数体里的变量则可能等到函数返回时才读取。

如果项目使用 Go 1.21 及更早的循环变量语义，循环声明的变量在多轮之间可能是同一个变量，延迟闭包就会共享它，最后看到循环结束后的值。Go 1.22 起，模块声明 go 1.22 或更高版本时，for 每轮会创建新的循环变量，这个旧陷阱不再自动出现；但显式声明在循环外、再不断赋值的变量仍然需要自己处理。

官方资料：https://go.dev/doc/effective_go#defer；https://go.dev/doc/go1.22

先看清 defer 是保存值还是保存读取动作

下面两段代码只差一个匿名函数，但含义完全不同。第一段把 i 作为参数传给 fmt.Println，参数在执行 defer 的那一刻就确定；第二段保存的是“以后再读取 i”的闭包。

package main

import "fmt"

func main() {
	for i := 0; i 

两类调用还会受到 defer 后进先出规则影响，所以不能只盯着“最后一个值”，还要确认多个延迟调用的执行顺序。官方 Effective Go 明确说明：延迟函数的参数（包括方法接收者）在 defer 执行时求值，而延迟函数会在外层函数返回前运行。

为什么旧版本会全部看到最后一个值

在旧语言语义下，下面的 v 是循环变量本身。每轮循环更新它，但闭包没有把当前值复制进自己的参数；所有延迟闭包都指向同一份变量。因为它们等到外层函数返回时才执行，此时循环已经结束，读取到的自然是最后一次赋值后的内容。

func printLater(values []string) {
	for _, v := range values {
		// 旧语言语义下，多个闭包可能共享循环变量 v。
		defer func() {
			fmt.Println(v)
		}()
	}
}

这也是“为什么输出最后一个值”的准确解释：不是闭包按逆序把每个历史值找回来，而是每个闭包都在执行时读取同一个变量。若用三段循环变量 0、1、2 举例，旧语义下常见结果是三个 3；如果是 range 切片，则常见结果是重复最后一个元素。

这里的“旧版本”要按模块语言版本判断，而不是只看本机安装的编译器。Go 1.22 的发布说明把循环变量改为每轮创建；模块的 go.mod 仍然决定是否启用新语义。

Go 1.22 后仍要检查哪些边界

如果 go.mod 写着 go 1.22 或更高版本，循环声明的变量在每轮拥有独立作用域，直接在闭包中引用它通常就能得到对应轮次的值。为了兼容旧模块，也为了让代码意图更明显，我仍会优先使用显式绑定。

func printLater(values []string) {
	for _, v := range values {
		// 通过参数把本轮值复制到闭包自己的参数 u。
		defer func(u string) {
			fmt.Println(u)
		}(v)
	}
}

func printLaterAgain(values []string) {
	for _, v := range values {
		v := v // 在循环体内创建本轮的新变量，兼容旧语义。
		defer func() {
			fmt.Println(v)
		}()
	}
}

还有一个很容易漏掉的边界：如果变量是在循环外声明的，Go 1.22 不会替你把它变成每轮变量。

func printOuter(values []string) {
	var v string
	for _, item := range values {
		v = item // v 在循环外，后续每轮都复用同一变量。
		defer func() {
			fmt.Println(v)
		}()
	}
}

因此，看到异常输出时先找变量声明位置，再看 go.mod 的语言版本；不要只根据“我已经安装了 Go 1.22”来下结论。

我现在排查这类问题会按四项确认

1. 先看写法：是 defer fmt.Println(v) 还是 defer func() { fmt.Println(v) }()。
2. 再看声明：变量由 for 头部声明、循环体重新声明，还是在循环外声明后反复赋值。
3. 再看版本：打开 go.mod，确认模块语言版本是否达到 go 1.22。
4. 最后看顺序：多个 defer 会后进先出，输出顺序和变量值问题可能同时存在。

我的取舍是：只要闭包要跨出当前迭代执行，就用闭包参数显式传值。它不依赖读者记住版本差异，也不会把“延迟执行”和“延迟取值”混成一件事。只有确实要共享一个外部状态时，才保留循环外变量，并在代码旁写清楚它的生命周期。

常见追问

为什么 defer fmt.Println(i) 也可能看起来顺序反了？

因为参数已经在注册时固定，但多个延迟调用仍按后进先出执行，所以值可能按倒序输出。它和闭包捕获同一个变量是两个独立问题。

Go 1.22 的新语义是不是让所有闭包都安全了？

不是。它只改变了循环声明变量的作用域；循环外反复赋值的变量、指针指向的共享对象，以及显式共享状态仍然需要按生命周期设计。