会丢——但不是Defer本身吞掉，而是你没显式处理error返回值；defer中调用返回error的函数若不检查或赋值，错误将静默丢失，尤其在HTTP handler中resp.Body.Close()失败时无提示。
Defer里调用带返回值的函数，错误真的丢了？
会丢——但不是Defer本身吞掉，而是你没显式处理error返回值。Go的defer执行时若函数返回error，而你既不赋值给变量、也不检查，那这个error就彻底没被任何人看到。
典型场景：在HTTP handler里defer resp.Body.Close()，如果Close()返回io.ErrUnexpectedEOF或网络中断导致的net.OpError，它不会panic，也不会打印，直接消失。
- 必须把
Close()等可能出错的操作包进一个匿名函数，并显式检查err - 不要写
defer f();当f()返回error时——这等于主动放弃诊断线索 - 命名返回值会让问题更隐蔽：如果函数本身有命名
err error返回值，又在defer里调用另一个返回error的函数，后者不会自动赋给外层err
func readData() (data []byte, err error) {
f, _ := os.Open("x.txt")
defer func() {
if e := f.Close(); e != nil {
err = e // 必须手动赋值，否则外层err仍是nil
}
}()
data, err = io.ReadAll(f)
return // 这里返回的err是ReadAll的结果，Close的err只在defer里覆盖过一次
}命名返回值 + Defer组合时，return语句实际发生了什么
命名返回值本质是函数栈帧里预声明的变量，return语句会先给这些变量赋值，再执行defer。关键点在于：defer里能读写这些命名变量，但不能“拦截”或“修改”已确定的返回动作——除非你在defer里重新赋值。
容易踩的坑是以为defer里的赋值会“覆盖最终返回值”，其实它只是改了那个变量，而该变量是否被最终返回，取决于return发生时它的值。
立即学习“go语言免费学习笔记（深入）”；
-
return一执行，命名变量就被赋予返回值；之后defer修改它，确实会影响返回结果 - 但如果
defer里调用的是另一个函数（比如log.Println(err)），且没对命名err赋值，那它对返回值毫无影响 - 多个
defer按后进先出顺序执行，最后一个defer对命名变量的写入，才是最终返回的值
func f() (err error) {
defer func() { err = fmt.Errorf("from defer 1") }()
defer func() { err = fmt.Errorf("from defer 2") }() // 这个生效
return nil // 实际返回的是"from defer 2"
}什么时候该避免命名返回值配合Defer
当函数逻辑分支多、错误来源分散，且你无法保证每个return前都合理控制命名变量的状态时，命名返回值+defer反而增加理解成本和出错概率。
典型高风险场景：数据库事务函数、嵌套IO操作、需要根据中间状态决定是否提前返回的校验逻辑。
- 优先用普通（非命名）返回值，显式写
return data, err——这样每条路径的错误来源清晰可查 - 如果坚持用命名返回值，所有
defer中涉及错误处理的地方，必须统一用if err == nil { err = e }模式，避免覆盖成功路径的nil - 别在
defer里做重试、恢复或状态修正——那是业务逻辑，不该混在资源清理里
Defer里安全处理错误的最小可行模式
不是不用defer，而是让它的错误处理变成“可见、可控、可追溯”。核心是：把错误检查从隐式变成显式，且不依赖命名返回值的副作用。
- 用
defer func() { if err := f(); err != nil { /* 记录或处理 */ } }()结构，永远显式接收err - 记录错误时优先用
log.Printf("close failed: %v", err)，而不是fmt.Println——前者默认带时间戳和goroutine ID - 对关键资源（如DB连接、文件锁），考虑不用
defer，改用ensure-style函数，在每个return前调用，确保错误必检 - 如果函数本身返回
error，且defer里的错误比主逻辑更重要（比如写文件后Sync()失败），那就该让Sync()的错误成为最终返回值，而不是忽略
最常被忽略的一点：很多标准库函数（如*os.File.Sync()、http.Response.Body.Close()）的错误，往往意味着数据已损坏或未持久化——它们不是“可以忽略的清理失败”，而是业务失败的延迟信号。
