Go defer 修改命名返回值时为什么需要用指针或闭包

写 Go 函数时，如果想让 defer 在返回前补充错误信息，关键不在“有没有用指针”，而在于延迟函数到底拿到了哪块可修改的存储。普通返回表达式已经是一个值；命名返回值则是函数帧里的返回槽位。后者可以被 defer 闭包直接赋值，前者不能凭空回写。

需要 defer 修改最终结果时，优先使用命名返回值加闭包；需要修改一个独立对象时传指针。若只是清理资源，保留普通返回值通常更清楚。

先区分普通返回值和命名返回值

最容易误判的是下面两种写法看起来都“在 return 之后执行 defer”，但能改到的对象不同：

package main

import "fmt"

func ordinary() int {
	result := 1
	// 这里捕获的是 result，闭包执行时仍能看到变量本身。
	defer func() { result++ }()
	return result
}

func named() (result int) {
	// result 是函数的命名返回槽位，可被延迟闭包赋值。
	defer func() { result++ }()
	return 1
}

func main() {
	fmt.Println(ordinary(), named()) // 1 2
}

ordinary 返回的是 return 表达式求出的副本，之后再改局部变量不会追回已经准备好的返回值。named 的 result 是返回槽位，return 1 会先把 1 放进去，defer 再把槽位加一，所以调用方拿到 2。

return 和 defer 到底先后影响什么

可以把命名返回函数理解成三块静态关系：函数帧保存命名返回槽位，return 表达式把结果写入槽位，defer 闭包仍然持有这个槽位的访问关系，最后调用方读取槽位。这里的“先后”不是 defer 重新执行 return，而是返回值已经准备好后，延迟函数还有一次修改机会。

还要注意参数求值时机：

func snapshot() (n int) {
	n = 1
	// 参数 n 在 defer 声明处求值，打印 1。
	defer fmt.Println(n)
	// 闭包读取的是执行时的命名返回槽位，打印 3。
	defer func() { fmt.Println(n) }()
	n = 3
	return
}

所以“用 defer 记录最终返回值”应使用闭包，而不是把变量直接作为普通参数传入。

指针和闭包分别改变了什么

当函数没有命名返回值时，如果确实要让延迟逻辑改动结果，可以显式把一个对象交给闭包。指针方案改的是对象，命名返回值闭包改的是返回槽位：

func wrap(errp *error) {
	// 指针指向调用方持有的错误对象，修改后调用方可见。
	if *errp != nil {
		*errp = fmt.Errorf("读取配置失败: %w", *errp)
	}
}

func load() (err error) {
	// 闭包直接改命名返回槽位，适合统一包装本函数返回的错误。
	defer func() {
		if err != nil {
			err = fmt.Errorf("加载阶段: %w", err)
		}
	}()
	return errors.New("文件不存在")
}

如果只是关闭文件、解锁互斥量或释放连接，defer 的职责是清理，不需要为了它改成命名返回值。只有错误包装、统计返回状态等确实需要“返回前最后一次修订”的场景，命名返回值才值得考虑。

错误包装时怎样选才不绕

实践中最稳的检查顺序是：先问 defer 要改的是返回槽位还是独立对象；再看 return 是否已经把值复制出去；最后确认错误包装不会覆盖原始错误。不要只因为“defer 要修改值”就机械加指针，指针解决的是共享对象可变性，不会让普通 return 表达式重新绑定到局部变量。

常见问题

为什么 defer func(){ x++ } 能看到最新的 x？

因为闭包捕获的是变量关系，调用在函数返回阶段执行；若写成 defer fmt.Println(x)，参数会在 defer 声明处求值。

非命名返回值能不能被 defer 修改？

不能直接修改已经准备好的返回表达式。可以改为命名返回值，或显式传入指向结果对象的指针。

命名返回值是不是总比普通返回值好？

不是。简单函数和资源清理更适合显式返回；命名返回值主要服务于 defer 错误包装等明确的尾部修订。