命名返回值可被 defer 修改，因在函数入口分配栈空间；匿名返回值不可修改，因 return 先拷贝值到临时变量。defer 参数求值时机分三种：声明时求值、闭包捕获地址、传值副本。多个 defer 按 LIFO 修改命名返回值，但链式叠加易出错且不可靠。
命名返回值才能被 defer 修改
匿名返回值（如 func() int）无法被 defer 改变，因为 return 42 实际会先拷贝 42 到一个临时栈变量，再退出；defer 里改的只是局部变量，不是那个临时值。只有命名返回值（如 func() (x int)）在函数入口就分配好栈空间，等价于 var x int，defer 闭包能直接读写它。
常见错误是写成这样：
func bad() int {
x := 42
defer func() { x = 99 }()
return x // 返回 42，不是 99
}
真正起效的写法必须具名：
func good() (x int) {
x = 42
defer func() { x = 99 }()
return // 或 return x，效果一样
}
defer 参数求值发生在声明时，不是执行时
这决定了你能不能“看到”后续修改：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
defer fmt.Println(x)：打印的是defer行执行那一刻的x值，之后改x不影响输出 -
defer func() { fmt.Println(x) }()：闭包捕获的是x的地址，打印的是最终值 -
defer func(val int) { fmt.Println(val) }(x)：传的是副本，x后续变化不体现
典型陷阱：
func example() (x int) {
x = 1
defer fmt.Println(x) // 输出 1，不是 2
x = 2
return
}
多个 defer 按 LIFO 顺序修改命名返回值
后定义的 defer 先执行，对命名返回值的修改会叠加：
func f() (x int) {
defer func() { x *= 2 }()
defer func() { x += 1 }()
return 3 // x = 3 → 第二个 defer: x = 4 → 第一个 defer: x = 8 → 返回 8
}
但别依赖这种链式叠加逻辑——可读性差，且一旦中间 panic，后续 defer 就不跑了，结果不可控。真需要多步处理，显式赋值更稳妥：
x = 3 x += 1 x *= 2 return
defer 修改只在函数作用域内有效，且不能逃逸
命名返回值变量本身不会逃逸到堆上，它的生命周期严格限定在函数内。即使你把它取地址传给 defer，只要没泄露出去，就不会有 GC 或并发问题。但要注意：
- 如果返回的是指针（如
func() *int），defer改的是指针指向的内容，不影响指针本身 - 闭包引用外部变量时，若该变量本就会逃逸，
defer不会额外加重负担 - 不要在
defer里启动 goroutine 并试图读写命名返回值——此时函数已退出，行为未定义
最易被忽略的一点：return 不是原子操作，但它的两步（赋值 + 跳转）之间没有调度点，所以 defer 修改是确定性的，前提是别混入异步或 panic 链。
