defer仅能修改命名返回值，因其在函数入口处声明为局部变量供defer引用；匿名返回值在return时才生成临时值，defer无法修改。
defer 修改的是命名返回值，不是返回值副本
go 中 defer 能修改函数返回值，但仅当该返回值是「命名返回参数」时才生效。这是因为命名返回值在函数入口处就已声明为局部变量，defer 语句捕获的是对这个变量的引用；而匿名返回值（如 func() int）在 return 执行时才生成临时值，defer 无法触及。
常见错误现象：写了 defer 修改返回值却没生效，大概率是因为用了匿名返回而非命名返回。
- ✅ 正确写法：
func foo() (x int) { x = 1; defer func() { x = 2 }(); return }→ 返回2 - ❌ 错误写法：
func foo() int { x := 1; defer func() { x = 2 }(); return x }→ 返回1（x是局部变量，与返回值无关） - 命名返回值会隐式初始化为零值，这点和局部变量一致，可直接在
defer中读写
return 语句的执行分两步：赋值 + RET 指令
Go 编译器把 return x 拆成两个动作：先将 x 的值复制给命名返回变量（或临时栈空间），再执行 RET 指令跳转。而 defer 函数在 RET 前执行，所以能覆盖命名返回变量的值，但无法改变已复制到返回栈帧里的匿名返回值。
这解释了为什么 defer 可以“拦截”返回过程——它插在赋值之后、真正退出之前。
- 对命名返回：
return 42→ 先赋值x = 42，再执行所有defer，最后RET - 对匿名返回：
return 42→ 先把42搬进返回栈槽，再执行defer，但栈槽内容不会被defer改变 - 可通过
go tool compile -S查看汇编，验证该行为
多个 defer 的执行顺序与返回值覆盖风险
多个 defer 按后进先出（LIFO）顺序执行，且都作用于同一组命名返回变量。这意味着后注册的 defer 有机会覆盖先注册的修改结果。
典型陷阱：在中间 defer 中设置返回值，又被后续 defer 清空或重写，导致逻辑失效。
-
func f() (err error) { defer func(){ err = errors.New("A") }(); defer func(){ err = nil }(); return errors.New("original") }→ 实际返回nil - 若需组合多个清理逻辑并保留错误，应显式检查
err != nil再决定是否覆盖 - 避免在不同
defer中无条件写同一个命名返回值，容易产生竞态式覆盖
defer 修改返回值在 panic/recover 场景下的特殊表现
当函数因 panic 退出时，命名返回值仍按常规流程处理：先完成所有 defer，再传递返回值（如果有的话）。但注意，recover 不会自动恢复返回值，它只捕获 panic；返回值是否生效，取决于函数是否最终正常返回。
也就是说，defer 中的修改只有在函数通过 return 正常退出时才体现；若 panic 未被 recover，则返回值根本不会被使用。
-
func f() (x int) { defer func(){ x = 99 }(); panic("boom") }→ 调用方收到的是零值0，不是99（因为未走到 return 路径） -
func f() (x int) { defer func(){ x = 99 }(); defer func(){ recover() }(); return 123 }→ 返回99（recover成功，函数继续执行完return） - 不要依赖
defer在 panic 流程中“修复”返回值，它不可靠
