defer 在 return 之后执行，能修改命名返回值、影响错误覆盖与包装，并通过 recover 拦截 panic；其参数在 defer 语句处求值，需闭包延迟读取；正确使用可修复错误，误用则埋下隐患。
有影响，而且影响很直接——defer 本身不处理错误，但它能决定错误是否被覆盖、是否被包装、甚至是否被 recover。
defer 和 return 的执行顺序：先 return，后 defer
这是最常被误解的一点。很多人以为 defer 在 return 之前运行，其实恰恰相反：return 语句会先完成值的赋值（尤其是命名返回值），然后才轮到所有 defer 执行。
-
return不是“跳转”，而是“赋值 + 标记函数即将退出” - 命名返回值（如
func foo() (err error)）在函数入口就分配内存，return只是往这块内存写值 -
defer函数可以读写这个命名返回值变量，从而修改最终返回结果
func example() (res string) {
res = "init"
defer func() {
res = "defer"
}()
return "return" // 这里把 "return" 写入 res
} // 实际返回的是 "return"，因为 defer 在 return 之后执行，但 res 已被覆盖为 "return"
// 注意：defer 中的赋值发生在 return 后，所以它会被 return 覆盖 —— 除非你没写 return 值
命名返回值 + defer 修改错误：常见且危险的模式
用命名返回值配合 defer 设置 err 是惯用写法，但极易因执行顺序或 panic 导致逻辑错乱。
- 如果函数中发生
panic，defer仍会执行，但return永远不会到达 —— 此时命名返回值保持零值，defer修改才真正生效 - 如果函数正常
return，而defer又修改了命名err，反而可能把原本正确的nil错误地改成非空 - 多个
defer修改同一命名返回值时，后注册的defer会覆盖先注册的（LIFO 顺序）
func risky() (err error) {
defer func() { err = fmt.Errorf("wrapped: %w", err) }()
return nil // 最终返回的是 "wrapped: <nil>"，不是 nil
}
defer 参数求值时机：别在 defer 里直接用变量名
defer 后面的函数参数，在 defer 语句执行那一刻就完成求值 —— 不是函数真正调用时。这对错误处理尤其关键。
- 如果你写
defer logError(err)，那err的值在defer那行就被捕获，后续err变了也无关 - 想捕获“最终的错误”，必须用闭包延迟读取：
defer func() { logError(err) }() - 同理，
time.Since(start)不能直接传进defer fmt.Println(time.Since(start))，否则记录的是 0s
func timing() {
start := time.Now()
defer fmt.Println("took:", time.Since(start)) // ❌ 错！start 是此刻求值，但 time.Since(start) 立即执行 → 0s
defer func() { fmt.Println("took:", time.Since(start)) }() // ✅ 对！闭包里延迟计算
time.Sleep(100 * time.Millisecond)
}
recover 和 defer 组合：唯一能拦截 panic 并转成 error 的方式
Go 没有 try/catch，defer + recover 是把 panic “降级”为普通错误的唯一标准路径。
-
recover()只在defer函数中有效，且仅对当前 goroutine 的 panic 生效 - 必须在 panic 发生前注册
defer，否则来不及捕获 - recover 返回
interface{}，需类型断言或用fmt.Errorf("%v", r)包装成error - 一旦
recover()成功，panic 就终止传播，函数继续执行后续代码（包括其他 defer）
func safeCall() (result string, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panicked: %v", r)
}
}()
panic("boom")
return "ok", nil // 这行不会执行
}
真正难的不是记住 LIFO 或参数求值，而是判断“这个 defer 是在修 bug，还是在埋雷”——尤其当它和命名返回值、recover、日志、计时混在一起时，一行 defer 可能悄悄改掉你整个错误链路。
