defer 中 close() 会覆盖真实错误，因后进先出且不检查返回值；应改用命名返回值+条件赋值或辅助函数捕获错误。
defer 里调用 Close() 为什么会吞掉真实错误？
因为 defer 执行顺序是后进先出，且不检查返回值。如果函数末尾已有一个非 nil 错误，而 defer 的 Close() 又返回另一个错误，前者会被后者覆盖——Go 不会自动合并或链式记录错误。
典型场景：打开文件后写入失败，接着 defer 关闭文件时磁盘满导致 Close() 返回 io.ErrShortWrite 或其他错误，原始的 os.PathError 就丢了。
- 永远不要直接写
defer f.Close()在可能出错的函数里 - 把
Close()放在显式 error 检查之后，或用辅助函数封装 - 若必须 defer，改用带错误捕获的模式：
defer func() { if err := f.Close(); err != nil && realErr == nil { realErr = err } }()
如何安全地组合多个 defer 资源清理？
多个资源（比如文件+数据库连接+HTTP body）需要关闭时，各自 defer 独立执行，但错误相互干扰风险更高——每个 Close() 都可能覆盖前一个错误。
常见错误现象：defer resp.Body.Close() 和 defer db.Close() 全堆在函数开头，结果最终只返回最后一个 Close() 的错误，完全掩盖了前面操作的真实失败原因。
立即学习“go语言免费学习笔记（深入）”；
- 按「使用顺序倒序」安排
defer：先 open 的资源后 close，避免依赖破坏 - 对每个关键资源做独立错误处理：不是所有
Close()都值得 panic，有些可忽略（如http.Response.Body），有些必须上报（如数据库连接） - 用命名返回值 + 条件赋值控制错误覆盖：
func readConfig() (err error) { ...; defer func() { if e := f.Close(); e != nil && err == nil { err = e } }() }
defer 在 panic 场景下还能保证资源释放吗？
能，但仅限于 panic 发生前已注册的 defer。panic 后程序不会继续执行后续语句，所以没来得及注册的 defer 不会生效。
性能影响很小，defer 本身开销固定，但大量嵌套或闭包捕获变量会略微增加栈帧大小；兼容性无问题，所有 Go 版本行为一致。
- panic 前注册的
defer仍会执行，包括那些调用Close()的 - 但注意：如果
Close()自身 panic，会中止当前 defer 链，后续 defer 不再执行 - 不要依赖
defer做“必须成功”的清理——例如释放系统级锁、删除临时文件，应优先用sync.Once或显式 cleanup 函数
有没有比 defer 更可控的资源管理方式？
有，但代价是代码变冗长。defer 是 Go 的默认约定，放弃它意味着主动承担更多手动控制责任。
适用场景：需要精确控制错误优先级、多资源间有强依赖、或集成外部 C 库需严格配对 alloc/free。
- 用结构体封装资源 + 实现
Close() error方法，配合命名返回值做错误聚合 - 小范围可用
goto跳转到 cleanup 标签（争议大，但确实避免 defer 的隐式时机） - 第三方库如
go.uber.org/multierr可合并多个错误，但不能改变 defer 执行顺序本身
真正容易被忽略的是：defer 不是银弹，它解决的是“延迟执行”，不是“错误传播”。错误覆盖问题本质是 Go 缺乏内置错误链机制，得靠程序员自己补位——哪怕只是加一行 if err == nil { err = closeErr }。
