defer f.Close() 不能用于长文件流，因它仅在函数返回时执行，而文件句柄常被移交其他 goroutine 持续使用，主函数快速返回导致 defer 未执行；若 goroutine 异常退出或进程终止，文件描述符泄漏，引发 too many open files 错误。
长文件流中 defer f.Close() 为什么不能用
因为 defer f.Close() 只在函数返回时执行，而长文件流（如日志归档、分块上传）常把 *os.File 交给其他 goroutine 持续读写，主函数很快返回，defer 根本没机会跑；更糟的是，若该 goroutine 因 panic、context 取消或信号中断提前退出，f 就彻底泄漏。
操作系统级文件描述符不会被 GC 回收，积压多了直接触发 too many open files 错误，尤其在长期运行的服务里。
- 不要在 goroutine 内部写
defer f.Close()后就扔给后台跑——os.Exit()或 SIGTERM 会让整个进程瞬间终止，defer 链完全不执行 - 不要复用循环变量：在
for range files中直接写defer file.Close()，所有 defer 实际绑定到最后一个file，前面的句柄全漏关 -
bufio.Reader或zip.File这类包装器不持有 fd，关它们 ≠ 关底层*os.File，必须显式调用原始句柄的Close()
io.ReadCloser 类型必须手动 Close()
很多标准库接口返回 io.ReadCloser（比如 http.Response.Body、zip.File.Open()、tar.Header.Open()），开发者常只读完内容就结束，忘了 Close()。
这类 Close() 不只是释放 fd，还可能清理解压缓冲、断开连接、刷写临时数据。漏关会导致连接池耗尽、磁盘空间涨、goroutine 卡死。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只要拿到
io.ReadCloser，就必须有且仅有一个明确的Close()调用点，哪怕只读几字节 - 别用
io.Copy(dst, rc)后直接 return —— 必须跟一句rc.Close()，并检查 error - 如果封装成函数返回
io.ReadCloser，文档要写清“调用方负责 Close”，否则使用者大概率漏
配合 context 控制长流生命周期
纯靠 Close() 不够——你得让流本身能响应取消。比如 io.Copy 传大文件时，即使上层 context 已超时，它仍会卡在底层 Read 直到 EOF 或出错。
解决方法是把 context 注入 I/O 链路，而不是等最后才关。
- 对已支持 context 的类型（如
http.Request.Body），确保上游 client 传了有效的req.Context() - 对
*os.File，可包装为自定义io.Reader，其Read()方法里加select { case - 避免用
io.CopyN+time.AfterFunc做中断——精度差、不及时，且无法区分 timeout 和 cancel
显式 Close 并检查 error 是唯一可靠方式
os.File.Close() 不是“无害收尾”。它会刷缓冲、同步元数据、释放内核句柄——这些都可能失败。忽略 error，等于放弃确认数据是否真正落盘。
尤其在 NFS、CIFS 或磁盘满场景下，Close() 返回 io.ErrUnexpectedEOF 或 syscall.ENOSPC 很常见。
- 正确写法：
if err := f.Close(); err != nil { log.Printf("failed to close %s: %v", f.Name(), err) } - 在重试循环中反复
OpenFile/Write，每次都要单独 checkClose()，不能只信第一次 - 多次调用
Close()是安全的（返回ErrClosed），但不应依赖这点来“补救”漏关
最易被忽略的一点：关闭顺序和时机比关闭动作本身更关键。比如 HTTP handler 里启动了一个写文件的 goroutine，这个 goroutine 必须监听同一个 context，并在 ctx.Done() 后完成写入再关文件；否则 shutdown 流程可能在它还没写完时就强制退出，导致数据截断或句柄残留。
