具名返回值可被defer修改，因其是函数栈上真实变量，return赋值后仍存在；匿名返回值无变量名，defer无法访问。defer在return赋值后、返回前执行，故能修改具名返回值。
defer 能修改具名返回值，是因为它操作的是函数作用域内真实存在的变量，不是临时拷贝；匿名返回值则没有这个变量，所以 defer 拿不到、改不了。
具名返回值变量在函数体全程可见
声明为 func foo() (x int) 时，x 是一个真实分配在栈上的局部变量，从函数入口就存在（初始化为零值），整个函数体包括所有 defer 都能读写它。这不是“返回值的别名”，它就是返回值本身。
- return 语句（比如
return 42）实际执行的是x = 42 - 随后触发
defer，此时x还没被传给调用方，修改它直接生效 - 函数最终返回的，就是这个被
defer修改后的x值
匿名返回值没有可访问的变量名
写成 func bar() int 时，Go 在底层会生成一个匿名的临时返回槽（比如叫 ~r0），但这个槽不暴露给开发者。你无法在函数体内声明或引用它，defer 自然也无从下手。
- return 语句（如
return 42）直接把 42 写进那个临时槽 -
defer中定义的局部变量（比如val := 42）和那个槽完全无关 - 即使你在
defer里改了val，对返回值毫无影响
defer 执行时机：在 return 赋值之后、真正返回之前
很多人误以为 defer 在 return 之前执行，其实顺序是：return 先完成赋值 → 然后逐个执行 defer → 最后跳转回 caller。这个窗口期，就是具名返回值能被修改的关键。
- 具名返回值：赋值后变量仍有效，
defer可读写 - 匿名返回值：赋值后值已落槽，
defer没有变量名去碰它 - panic 场景下同样适用：panic 触发后，先走完所有
defer，再向上抛，所以defer依然能改具名返回值
闭包捕获 vs 参数预求值：容易混淆的两个点
这两个机制常被混为一谈，但它们影响的是不同东西：
-
defer fmt.Println(x)：参数x在defer语句执行时就被求值并拷贝（值类型），后续改x不影响输出 -
defer func() { fmt.Println(x) }()：这是闭包，x是运行时动态读取，输出的是defer实际执行时的值 - 但无论哪种，只要
x是具名返回值，闭包里的x++就真能改返回值；而第一种写法里的fmt.Println(x)只是“看一眼”，不改
最易忽略的一点：具名返回值的变量名在函数内全局可见，包括所有 defer 闭包——这和普通局部变量的生命周期一致，不是特殊语法糖。一旦记成“return 后变量就销毁”，就会误判 defer 的能力边界。
