直接调用 Close() 易致资源泄漏，因提前返回、忽略错误或漏关嵌套 io.Closer；应显式检查关闭错误、用 errors.Join 合并多资源关闭结果，并明确关闭责任与时机。
为什么直接调用 Close() 容易出问题
手动在函数末尾写 defer f.Close() 看似稳妥，但一旦函数提前返回（比如 return err）、或 Close() 本身返回错误被忽略，资源就可能泄漏。更隐蔽的是：如果一个结构体嵌套多个 io.Closer（如含多个文件、网络连接），只关一个而漏掉其余，照样泄漏。
defer + if err != nil 不是万能解法
常见误区是这样写：
func processFile(path string) error {
f, err := os.Open(path)
if err != nil {
return err
}
defer f.Close() // ❌ 这里 Close() 错误被静默丢弃
// ... 处理逻辑
return nil
}
问题在于：f.Close() 可能失败（例如磁盘已满导致 flush 失败），但 defer 不检查它的返回值。正确做法是显式捕获并处理关闭错误，尤其在关键流程中：
- 若业务允许忽略关闭错误（如只读文件），至少加日志：
if err := f.Close(); err != nil { log.Printf("close %s: %v", path, err) } - 若必须保证关闭成功（如写入临时文件后需原子重命名），应把
Close()放到业务逻辑之后、return之前，并检查错误 - 不要在
defer中调用可能 panic 的方法（如未判空的指针方法）
用 errors.Join() 合并多个 Close() 错误
当一个对象持有多个 io.Closer（比如自定义的 MultiWriter 或数据库事务封装），不能只关第一个。Go 1.20+ 推荐用 errors.Join() 汇总所有关闭错误：
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
type ResourceManager struct {
db *sql.DB
file *os.File
conn net.Conn
}
func (r *ResourceManager) Close() error {
var errs []error
if r.db != nil {
errs = append(errs, r.db.Close())
}
if r.file != nil {
errs = append(errs, r.file.Close())
}
if r.conn != nil {
errs = append(errs, r.conn.Close())
}
return errors.Join(errs...)
}
这样调用方能统一判断是否全部关闭成功，而不是靠“最后一个 Close() 返回值”做决策。
别依赖 io.Closer 的隐式生命周期管理
io.Closer 只是一个接口，不带任何自动清理语义。它不会触发 GC、不绑定 goroutine 生命周期、也不阻止重复调用（多数实现对重复 Close() 做幂等处理，但不是强制规范）。实际使用中要注意：
- 避免在多个 goroutine 中并发调用同一个
io.Closer的Close()—— 即使是幂等的，也可能因竞态导致日志混乱或资源状态错乱 - 不要假设
Close()一调用，底层 fd 就立刻释放；某些系统调用（如shutdown(2)）可能异步完成 - 测试时用
runtime.NumGoroutine()或pprof观察 goroutine 泄漏，比单看Close()调用次数更可靠
真正难的不是写 Close()，而是确定「谁该负责关」「什么时候关最安全」「关失败了要不要重试或告警」——这些都得结合具体资源类型和业务语义来定。
