Go defer 参数什么时候求值：为什么打印的是旧值

Go 里 defer 很常用，但也很容易让人困惑：变量后面明明改了，为什么延迟调用打印的还是旧值？闭包写法又为什么能看到新值？如果函数有命名返回值，defer 又能不能改返回结果？

这篇 Go 问答按完整工作流来讲：先定清楚 defer 的使用边界，再用一段最小代码看参数保存时机，接着拆解传参、闭包、命名返回值和多个 defer 的触发顺序，最后给出可复用写法和测试清单。

目标和边界：defer 解决的是收尾，不是延后求值

先说结论：defer 的核心价值是把清理、解锁、关闭资源、补充日志、包装错误这类“函数结束前必须做”的动作放到靠近申请资源的位置。它不是让所有表达式都等到函数返回前才计算。

更准确地说，defer 语句被运行到时，会先确定要调用的函数和实参；真正调用会延后到当前函数返回前，并且多个 defer 会按后进先出顺序触发。

全流程总览：defer 从注册到返回前调用

下面这张图把最常见的“打印旧值”过程拆开：变量初始是 0，注册 defer 时参数已经保存，后面变量变成 1，函数返回前触发延迟调用时，打印的仍然是保存下来的 0。

阶段一：先复现为什么打印旧值

先看最小代码：

package main

import "fmt"

func main() {
	i := 0
	defer fmt.Println(i)
	i++
}

很多人会猜输出 1，但实际输出是：

0

原因不是 defer 看不到变量修改，而是 fmt.Println(i) 里的实参 i 在注册 defer 时已经被取值并保存了。后面的 i++ 改的是变量本身，不会回头改掉延迟调用里已经保存的实参。

阶段二：理解参数、函数值和栈式触发

可以把 defer 想成往当前函数的延迟调用栈里压入一个任务。压入时要先确定两个东西：

• 要调用哪个函数。
• 这个函数调用需要哪些实参。

多个 defer 会按后进先出顺序触发：

func demo() {
	defer fmt.Println("A")
	defer fmt.Println("B")
	defer fmt.Println("C")
}

输出顺序是：

C
B
A

这个规则很适合资源收尾：后申请的资源通常先释放，能减少依赖顺序上的问题。

阶段三：参数、闭包和命名返回值怎么选

同样是 defer，不同写法表达的意图不一样。写代码时最好先问：我想保存当前快照，还是想在返回前读取最新状态？

1. 想保存当前值：直接传参

func demo() {
	x := 1
	defer logValue(x)
	x = 2
}

这里 logValue 收到的是 1。适合记录进入函数时的参数、资源编号、开始状态等。

2. 想读取最新值：使用闭包

func demo() {
	x := 1
	defer func() {
		logValue(x)
	}()
	x = 2
}

闭包里没有把 x 当作实参传进去，而是在延迟调用真正触发时读取外层变量，所以这里会看到 2。适合记录最终状态、耗时后的统计值、退出前的错误信息等。

3. 想改返回结果：使用命名返回值

func load() (err error) {
	defer func() {
		if err != nil {
			err = fmt.Errorf("load failed: %w", err)
		}
	}()

	err = readConfig()
	return
}

命名返回值在函数返回流程中仍可被 defer 修改。这个写法常用于给错误补上下文，但要克制使用，避免返回路径过于隐蔽。

阶段四：用测试固定 defer 行为

如果一段代码依赖 defer 的顺序、参数保存或命名返回值修改，最好写测试锁住行为。

func TestDeferArgValue(t *testing.T) {
	got := make([]int, 0, 1)

	func() {
		x := 1
		defer func(v int) {
			got = append(got, v)
		}(x)
		x = 2
	}()

	if got[0] != 1 {
		t.Fatalf("want 1, got %d", got[0])
	}
}

这个测试表达得很明确：传参写法保存的是注册时的值。如果后来有人把它改成闭包读取，测试会及时提醒行为变化。

我的推荐流程

1. 先判断 defer 是用来释放资源、写日志、包装错误，还是改返回值。
2. 需要保存当前快照时，用直接传参。
3. 需要读取最终状态时，用闭包读取外层变量。
4. 需要包装返回错误时，使用命名返回值，并把逻辑写得短而清楚。
5. 多个 defer 同时存在时，按后进先出顺序检查资源释放是否合理。
6. 对顺序和返回值有依赖的代码，补测试确认。

容易踩坑的地方

• 误以为 defer fmt.Println(i) 会在函数返回前才读取 i。
• 把闭包和传参写法混用，导致日志里有时是旧值，有时是新值。
• 在 defer 里修改命名返回值太复杂，让调用方很难判断错误来源。
• 多个 defer 的顺序想反，导致资源释放顺序不符合依赖关系。
• 只靠肉眼判断，没有用测试固定关键行为。

落地速查表

一句话记住：defer 延后的是调用时机，不是所有实参的计算时机。想要固定值就传参，想要最新状态就用闭包，想要改返回值就让命名返回值承担这个意图。