defer 与命名返回值叠加时的结果修改边界？

结论先说：return 设置结果值后，函数才会执行已经登记的 defer。如果结果参数是命名的，defer 闭包可以在这段时间里修改它，调用方拿到的就是修改后的值；如果结果没有命名，defer 只能修改自己能访问到的局部变量，不能回头改写已经准备好的返回槽位。

这个边界同时适用于普通返回和 panic 恢复。最常见的工程用法是把命名的 error 交给 defer 做统一包装，或者在 defer 中调用 recover，把 panic 转成错误返回。

先记住 return 和 defer 的先后关系

Go 规范把返回过程分成两个关键动作：先计算显式返回表达式并设置结果参数，再按后进先出顺序执行 defer，最后才回到调用方。因此，命名结果参数在 defer 中仍然是可读写的普通局部变量。

func multiply() (result int) {
	// 先把 6 写入命名结果参数，defer 再读取并修改它。
	defer func() {
		result *= 7
	}()
	return 6
}

// 调用 multiply() 得到 42。

return 6 并不是把一个不可变的临时值直接交给调用方。它先把 6 放入 result，随后 defer 闭包把 result 乘以 7，所以最终结果是 42。defer 闭包有返回值也没有意义，它的返回值会被丢弃。

最小配方：用命名 error 做统一包装

如果一个函数需要给底层错误补充当前操作上下文，可以声明命名的 err，在 defer 中判断并包装。显式 return 仍然可以使用，这样调用点的错误来源更清楚。

package main

import (
	"errors"
	"fmt"
)

func loadConfig() (err error) {
	defer func() {
		// return 已经把底层错误写入 err，这里只补充调用上下文。
		if err != nil {
			err = fmt.Errorf("load config: %w", err)
		}
	}()

	// 示例用固定错误代表真实的文件或网络失败。
	return errors.New("file not found")
}

func main() {
	fmt.Println(loadConfig())
}

调用方看到的是 load config: file not found，而不是未包装的底层错误。这里的关键不是“defer 能修改任意返回值”，而是 err 本身就是函数的命名结果参数。

未命名结果：改局部变量不会改返回值

下面的写法容易造成误判：defer 确实把局部变量 err 改成了 nil，但返回表达式执行时，函数的结果槽位已经拿到了原来的错误。由于函数签名没有命名结果参数，defer 没有可直接修改的返回变量。

func notWrapped() error {
	err := errors.New("temporary failure")
	defer func() {
		// 这里只修改局部 err，不能改写已经准备返回的结果。
		err = nil
	}()
	return err
}

// notWrapped() 仍然返回 temporary failure，而不是 nil。

这也是为什么“把变量改掉了但调用方仍收到旧值”不是编译器异常，而是返回时机符合规范。若确实需要在统一收尾逻辑中改写结果，就把结果参数命名；如果不希望隐藏控制流，则直接在每个返回点显式包装错误。

defer 的参数是快照，闭包才会读取后续值

另一个边界来自 defer 语句本身：defer 调用的函数值和参数会在登记时求值。直接把 err 作为参数传进去，拿到的是当时的值；闭包捕获命名结果参数，则会在真正执行时读取它。

func snapshotVsClosure() (err error) {
	err = errors.New("original")

	defer fmt.Println("snapshot:", err)
	defer func() {
		// 闭包在函数返回前执行，读取的是当前 err。
		fmt.Println("closure:", err)
	}()

	err = errors.New("updated")
	return
}

// 输出顺序为 closure: updated，然后 snapshot: original。

两个 defer 还遵守后进先出顺序，所以后登记的闭包先执行。排查这类问题时，先区分“参数快照”和“闭包读取”，再检查 defer 的登记顺序。

shadowing 会让裸 return 失去可读性

命名结果参数是普通变量，内层代码仍可能用 := 声明同名变量。此时裸 return 要求编译器判断当前作用域的名字是否遮蔽了结果参数；即使代码能通过，也很难让读者确认返回的是哪一个变量。工程代码中建议在内层分支使用显式返回，或改用不易重名的局部变量。

func parseValue(input string) (value int, err error) {
	if input == "" {
		// 显式返回避免内层变量和命名结果的作用域混淆。
		return 0, errors.New("empty input")
	}

	value = len(input)
	return value, nil
}

不要把“能裸 return”当成必须使用的风格。命名返回值适合和 defer 的收尾逻辑配合，但返回路径多、局部变量多时，显式返回往往更容易审查。

recover：在 defer 中把 panic 转成 error

recover 只有在 panic 正在沿当前 goroutine 的栈展开，并且由 defer 函数直接调用时才有作用。恢复函数通常把命名的 err 设为错误，并按约定把其它结果清零，避免调用方误用部分结果。

func safeCompute() (value int, err error) {
	defer func() {
		// recover 必须直接位于 deferred 函数中，才能截住本 goroutine 的 panic。
		if recovered := recover(); recovered != nil {
			value = 0
			err = fmt.Errorf("compute panic: %v", recovered)
		}
	}()

	panic("invalid input")
}

发生 panic 后，defer 闭包执行并调用 recover，接着函数以命名结果返回 0 和包装后的错误。若把 recover 放到另一个普通函数里，或者在没有 panic 时调用，它会得到 nil，不能当作任意位置的异常捕获器。

工程上怎么选

可以把判断口诀记成三句：return 先写结果，defer 再做收尾，只有命名结果能被闭包直接改写。再加上 defer 参数是快照、recover 必须在 deferred 函数中直接调用，基本就能解释大多数“返回值怎么变了”的问题。

常见追问

defer 能修改未命名返回值吗？

不能直接修改返回槽位。它可以修改仍在作用域中的局部变量，但该变量若已作为返回表达式求值，通常不会影响已经准备好的结果。

命名返回值一定要使用裸 return 吗？

不需要。命名结果只是让结果变量在函数体和 defer 闭包中可见，仍然可以使用显式的 return value, err。

recover 放在普通辅助函数里为什么接不到 panic？

因为 recover 必须由正在执行的 deferred 函数直接调用，并且要处于同一个 goroutine 的 panic 展开过程。