defer在return执行后、函数真正返回前触发；具名返回值在return时已赋值，defer可修改并影响最终返回值，匿名返回值则不受defer中同名局部变量修改的影响。
defer 在 return 语句执行后、函数真正返回前触发
Go 的 defer 不是在函数调用时立即执行，也不是在函数末尾“自然结束”时才跑，而是在函数控制流即将离开当前函数（即执行 return）的**那一刻之后、实际返回调用者之前**执行。这个时机对具名返回值特别关键——因为具名返回值在函数签名里就已声明为局部变量，defer 中能访问并修改它，但前提是修改发生在 return 语句“写入”该变量之后。
具名返回值在 return 执行时已被赋值，defer 可以覆写
当函数使用具名返回值（如 func foo() (x int) { ... }），Go 编译器会把所有 return 语句隐式转为先给 x 赋值，再执行 defer，最后返回。这意味着：
-
defer函数体内读写的x是那个即将被返回的变量，不是副本 - 如果
defer修改了x，最终返回的就是修改后的值 - 但如果
return语句带表达式（如return 42），赋值动作发生在defer前；若用return无参数形式，则必须依赖具名值已有值（或零值）
示例：
func f() (x int) {
defer func() { x++ }()
return 10 // 实际执行顺序：x = 10 → 执行 defer → 返回 x（此时 x 是 11）
}
// f() 返回 11，不是 10
匿名返回值 + defer 修改局部变量 ≠ 修改返回值
这是最容易混淆的点：如果函数是匿名返回值（如 func() int），哪怕你在函数内定义同名局部变量 x，defer 修改它也**不会影响返回值**，因为返回值没有绑定到该变量。
- 匿名返回值是临时结果，由
return表达式直接确定，不经过具名变量存储 - 具名返回值才是编译器生成的、与函数作用域绑定的变量，
defer才能捕获它 - 常见错误：以为
defer fmt.Println(x)中的x是返回值，其实只是闭包捕获的局部变量
对比：
// ❌ 不影响返回值
func g() int {
x := 5
defer func() { x++ }()
return x // 返回 5，defer 中 x++ 不改变返回结果
}
// ✅ 影响返回值
func h() (x int) {
defer func() { x++ }()
return 5 // 返回 6
panic/recover 场景下 defer 仍按序执行，但返回值行为一致
即使函数因 panic 中断，已注册的 defer 依然会执行，且对具名返回值的修改逻辑不变。但要注意：
- 如果
defer内部recover()捕获 panic，函数可正常返回，此时具名返回值仍受defer修改影响 - 如果多个
defer都改同一个具名返回值，后注册的先执行（LIFO），所以最终生效的是最后一个defer的修改 - 在
defer中修改具名返回值时，不要依赖它“尚未被 return 写入”——它一定已经被写了，只是还没传出
真正容易被忽略的是：具名返回值的初始化发生在函数入口，而非 return 那一刻；所以即使没显式赋值，它也有零值，defer 修改的是这个早已存在的变量。
