必须显式关闭文件句柄，不可依赖gc；复用指同一*os.file实例多处使用并统一关闭，而非反复openfile后各自close，否则导致fd泄漏和too many open files错误。
文件句柄不能“复用”——必须显式关闭后重新打开，但可以安全地“复用变量”和“复用已打开的句柄实例”。 直接把一个 *os.File 传给多个写入函数、或在不同 goroutine 中并发读写同一句柄，不加同步是危险的；而反复 os.OpenFile 后不 Close()，则必然泄漏。真正的复用，是“一次打开、多处使用、统一关闭”。
为什么不能在多个函数里各自 OpenFile 再 Close
每个 os.OpenFile 都会申请一个新的文件描述符（fd），即使路径相同。若 A 函数打开后写了点内容就 Close()，B 函数再打开，就不是同一个 fd，也无法延续上次的偏移位置或缓冲状态。更严重的是：如果忘了某处 Close()，fd 数量会随调用次数线性增长，触发 too many open files 错误。
- 常见错误现象：
open /tmp/log.txt: too many open files - 典型场景：HTTP handler 每次请求都
os.OpenFile("access.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)并直接写，没复用 - 根本原因：文件句柄是操作系统资源，不是 Go 变量值，无法靠赋值“共享”
如何安全地跨函数使用同一个 *os.File
核心原则：**打开逻辑与使用逻辑分离，句柄生命周期由单一责任方管理**。推荐用结构体封装，避免裸指针传递：
- 定义结构体持有
*os.File和业务逻辑方法（如WriteLog()、Rotate()） - 提供明确的
Open()和Close()方法，且Close()应幂等（多次调用无副作用） - 调用方只调用
Open()一次，在程序退出前调用Close()；中间所有写操作都通过该结构体方法进行 - 若需并发写，结构体内加
sync.Mutex或直接用log.Logger（它自带锁）
示例中 FileScanner 就是这种思路的延伸——它把 *os.File 和 *bufio.Scanner 绑定，确保扫描器生命周期与文件句柄一致。
bufio.Writer 的复用依赖于底层 io.Writer 是否还有效
bufio.NewWriter 接收任意 io.Writer，但它本身不管理底层资源。一旦你传入的 *os.File 被 Close()，后续对 bufio.Writer 的 Write() 或 Flush() 就会失败（返回 io.ErrClosedPipe 或类似错误），且不会 panic。
- 容易踩的坑：在 defer
f.Close()后，还试图调用w.Flush()，此时w已失效 - 正确顺序：先
w.Flush()，再f.Close()；或者用defer w.Flush()+defer f.Close()，但要注意 defer 执行顺序是后进先出 - 性能影响：每次新建
bufio.Writer开销极小，但频繁创建/销毁会增加 GC 压力；长期运行服务应复用单个bufio.Writer实例
最易被忽略的一点：**os.File 是线程安全的，但仅限于系统调用层面的原子性（如单次 write(2)）；bufio.Writer 的缓冲区操作不是并发安全的，多个 goroutine 共享同一个 bufio.Writer 必须加锁，或改用每个 goroutine 独立的 writer + 共享底层 *os.File（仍需锁）**。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
