命名返回值能被 defer 修改，是因为它本质是函数内分配的局部变量，生命周期覆盖整个函数体且最终用作返回值；defer 在 return 赋值后、返回前执行，可修改该变量，但仅限同步闭包，异步操作会导致未定义行为。
命名返回值能被 defer 修改，是因为它本质是局部变量
Go 编译器在遇到 func f() (x int) 这类签名时，会在函数入口就为 x 分配栈空间，并初始化为零值（0）。它不是“返回值的别名”，而是和 var x int 完全等价的局部变量——只是生命周期覆盖整个函数体，且最终被用作返回值。
这意味着你在任何位置（包括所有 defer）读写 x，操作的都是同一块内存。常见错误是以为 return 42 是原子跳转，其实它等价于 x = 42; goto defer_phase;。赋值完成后，x 的值已确定，但尚未传出函数，这正是 defer 能修改它的窗口期。
-
defer func() { x = 10 }()—— 有效：闭包直接引用x地址 -
defer fmt.Println(x)—— 无效于修改：参数在defer行执行时就求值并拷贝，后续改x不影响输出 -
defer func(val int) { val = 10 }(x)—— 无效：传入的是x的副本，改了没用
匿名返回值无法被 defer 修改，因为没有变量可写
像 func f() int { return 3 + 4 } 这种写法，返回的是一个临时计算结果，不是变量。defer 函数里根本看不到这个值，更谈不上修改。
即使你在函数内声明了 var result int，只要返回类型没命名，defer 就无法影响最终返回值。例如：
func bad() int {
x := 42
defer func() { x = 99 }()
return x
}
返回仍是 42——defer 改的是局部变量 x，不是返回值本身。
想让 defer 影响返回值，必须把返回值“具名化”，否则它对返回值完全无感。
多个 defer 按 LIFO 顺序执行，修改会叠加
defer 按后进先出顺序执行，而每个 defer 对命名返回值的修改是叠加的。例如：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
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。
- 顺序反过来，结果就变成
7 - 若某个
defer中又panic，后续defer就不跑了，x的最终值取决于中断点 - 不要依赖这种隐式叠加逻辑；真正需要链式修改时，显式赋值更清晰可靠
defer 修改只在函数作用域内生效，且不可逃逸
命名返回值的变量名在函数内全局可见，包括所有 defer 闭包——这和普通局部变量的生命周期一致，不是特殊语法糖。
最易被忽略的一点是：一旦函数返回，这个变量生命周期就结束。它不是全局或逃逸出去的引用。
以下写法危险且无效：
defer func() {
go func() { x = 99 }()
}()
x 的栈帧在函数返回后立即失效，goroutine 读写的是已释放内存，行为未定义。
所有对命名返回值的修改，必须发生在同步执行的 defer 函数内，不能靠异步手段去碰它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
