goroutine 中 defer file.close() 不会执行，因 defer 绑定 goroutine 栈帧而非全局资源；须用 context.done() 显式关闭并配合 sync.once 防重关，封装结构体提供统一 close() 方法管理生命周期。
defer file.Close() 在 goroutine 中根本不会执行
goroutine 退出时，其内部的 defer 不会像主函数那样被自动触发。如果在 goroutine 里打开文件后只写 defer file.Close()，而该 goroutine 因主流程结束、channel 关闭或 context 取消提前退出，file.Close() 就永远不会调用 —— 文件描述符持续泄漏。
- 常见错误现象：程序跑一段时间后报
too many open files，但查不到明显未关闭的文件 - 根本原因：goroutine 生命周期独立于主函数，
defer绑定的是 goroutine 的栈帧，不是全局资源管理器 - 正确做法：把文件关闭逻辑和 goroutine 的退出信号对齐，不能依赖 defer 自动兜底
用 context.Done() + 显式 Close() 替代 defer
在 goroutine 内部，应监听 ctx.Done() 并在收到信号后主动调用 file.Close()，同时检查返回值。这比 defer 更可控，也符合 Go 的显式资源管理哲学。
- 必须在
select分支中处理ctx.Done()后立即关闭文件，而不是等 goroutine 自然退出 -
file.Close()可能返回 error（如 NFS 断连、磁盘满），需记录但不 panic：log.Printf("failed to close %s: %v", path, cerr) - 避免在
default分支里反复读写时遗漏关闭 —— 关闭动作只应在明确终止路径上发生一次
跨 goroutine 共享文件句柄时的关闭竞争
多个 goroutine 同时读写同一个 *os.File 是安全的，但关闭操作不是线程安全的。若一个 goroutine 调用了 file.Close()，其他 goroutine 再调用会返回 io.ErrClosed；若没做防护，可能引发日志刷屏或掩盖真实错误。
- 典型场景：一个 goroutine 负责写入日志，另一个监听 signal 或 timeout 后触发关闭
- 推荐方案：用
sync.Once包裹file.Close()，确保只关一次：once.Do(func() { file.Close() }) - 不要靠判断
file == nil来规避重复关闭 ——Close()后file仍非 nil，只是内部 fd 已释放
结构体封装 + Close() 方法是长期持有文件的唯一可靠方式
当文件需要被多个 goroutine 协作使用（如日志 writer、配置热加载 reader），必须把 *os.File 封装进结构体，并提供显式的 Close() 方法，由调用方统一控制生命周期。
- 结构体内应保存
sync.Once和关闭状态标记，避免多次调用Close()导致 panic 或误报 - 禁止在结构体方法内部用
defer file.Close()—— 这会让关闭时机失控，变成“谁先调用谁关” - 示例关键逻辑：
func (w *LogFileWriter) Close() error { return w.once.Do(func() { w.file.Close() }) }
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
