defer 在 return 赋值后、函数退出前执行，命名返回值因是栈上可寻址局部变量，能被 defer 修改；匿名返回值无变量绑定，无法被 defer 影响；defer 参数在声明时求值，修改需闭包；多 defer 按 lifo 执行，panic 不阻断其运行。
defer 在 return 赋值之后、函数真正退出之前执行，不是“return 完了 defer 才开始”，而是 return 先把值写进命名返回变量，再轮到 defer 运行。
命名返回值能被 defer 修改，是因为它本质是局部变量
函数签名里带名字的返回值（比如 func f() (x int)）会在函数入口就声明为同名局部变量，初始为零值，整个生命周期都在栈上可寻址。
-
return 5实际是给这个已存在的x赋值，不是构造新值 -
defer func() { x++ }()读写的是同一个内存地址，修改立即生效 - 即使
return后面没写变量名（如直接return），只要函数有命名返回值，它仍会用当前值返回
匿名返回值无法被 defer 修改，因为没有变量可捕获
像 func f() int { return 42 } 这种写法，返回值是临时计算结果，不绑定任何变量名，也不分配独立地址。
-
defer func() { fmt.Println(x) }()中的x如果是局部变量，打印的是那个局部变量，不是返回值本身 - 哪怕你
return x，defer里改x = 99，函数仍返回x在return那一刻的副本值 - 想让 defer 影响返回结果，唯一办法是把返回值“具名化”——写成
func f() (x int)
defer 参数求值时机常被误判，导致修改失效
defer 语句里的参数在 defer 行执行时就求值快照，不是 defer 真正调用时才读取。
-
i := 0; defer fmt.Println(i); i = 42→ 输出0，不是42 - 想读最终值，得用闭包：
defer func() { fmt.Println(i) }() - 对命名返回值也适用：如果
defer func(x int) { x++ }(res)，传的是副本，res不变；必须写成defer func() { res++ }()
多个 defer 按后进先出（LIFO）顺序执行
最后注册的 defer 最先运行，这影响返回值的最终状态。
-
defer func() { x++ }(); defer func() { x *= 2 }(); return 3→ 最终返回8（先 ×2 得 6，再 +1 得 7？不对：实际是后注册的x++先执行，x从 3→4；再执行x *= 2，得 8） - 资源清理场景下这个顺序很合理，但修改返回值时容易绕晕，建议只用一个 defer 改返回值，或显式赋值再 return
- panic 不影响已注册的 defer，它们仍会执行，所以命名返回值可能被 panic 前的 defer 改过，也可能被 recover 后的逻辑覆盖
最易忽略的一点是：defer 对返回值的干预能力完全依赖命名返回值这个语法特性。不声明名字，就等于放弃控制权——这不是 bug，是 Go 的确定性设计，得靠写法去适配，而不是靠技巧去绕开。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
