命名返回值是函数栈帧中真实可寻址的局部变量，非语法糖；return 42 实质为 x = 42，defer 在赋值后、函数真正返回前执行，可直接修改该变量。
命名返回值不是语法糖，是真实栈变量
Go 编译器遇到 func f() (x int) 这类签名时，会在函数入口就为 x 分配栈空间，并初始化为零值（0）。它和你在函数开头写 var x int 完全等价——不是“返回值的别名”，而是有地址、可寻址、可被所有 defer 闭包直接读写的局部变量。
这意味着：return 42 并非跳过变量直接返回字面量，而是编译器自动展开为 x = 42，再进入 defer 执行阶段。这个赋值完成但尚未传出的窗口，就是 defer 能修改它的唯一时机。
常见错误现象：以为 return 是原子跳转，结果在 defer 里改了没生效——大概率是因为用了参数传值而非闭包捕获，或者误用了匿名返回值函数。
defer 参数求值时机 vs 函数体执行时机
这两者完全分离，且极易混淆：
立即学习“go语言免费学习笔记（深入）”；
-
defer fmt.Println(x)：这里的x在 defer 语句执行时（即return前）就被取值并拷贝，后续x变了也看不到 -
defer func() { x++ }()：闭包捕获的是x的地址，函数体在return后、真正退出前执行，此时修改的是已赋值的栈变量 -
defer func(val int) { val = 10 }(x)：val是x的副本，改了不影响x
性能上无额外开销，但逻辑上容易自相矛盾：同一个 x，在 defer fmt.Println(x) 里输出的是注册时的快照，在 defer func(){x++}() 里改的是 return 后的值。
多个 defer 按 LIFO 顺序叠加修改命名返回值
注册顺序决定执行逆序，而每次修改都作用于同一块内存。例如：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func f() (x int) {
defer func() { x *= 2 }()
defer func() { x += 1 }()
return 3
}
执行流是：return 3 → x = 3 → 执行第二个 defer（x += 1 → x = 4）→ 执行第一个 defer（x *= 2 → x = 8）→ 返回 8。
如果交换两行 defer 注册顺序，结果变成 7。这不是 bug，而是机制必然——但生产代码中应避免依赖这种隐式叠加。显式赋值更清晰，比如把逻辑提前到 return 前。
panic 场景下同样适用：所有已注册 defer 仍会按 LIFO 执行，但如果某个 defer 里又 panic，则后续 defer 不再运行，x 最终值取决于中断点。
goroutine 异步修改命名返回值是未定义行为
以下写法危险且无效：
defer func() {
go func() { x = 99 }()
}()
原因很直接：x 是函数栈帧上的变量，函数返回后栈帧立即回收，goroutine 读写的是已释放内存，行为未定义（可能 crash，也可能看似正常但结果不可靠）。
最容易被忽略的边界是作用域：命名返回值只在函数作用域内有效，任何试图跨 goroutine 或跨函数生命周期访问它的操作，都不受语言保证。
