不能复用*os.file，因其绑定内核fd、含偏移/锁/关闭状态等不可复制资源，pool复用会导致竞态、ebadf或脏数据；正确做法是用chan管理预开句柄池并显式重置状态，或改用mmap、批量i/o、sync.pool复用缓冲区。
Go 里不能用 sync.Pool 直接复用 *os.File 对象——文件句柄不是临时对象，复用它会引发竞态、泄漏、或 EBADF 错误。
为什么不能把 *os.File 放进 sync.Pool
sync.Pool 设计目标是短生命周期、无状态、可丢弃的临时对象（比如 []byte、*bytes.Buffer）。而 *os.File 是有内核资源绑定的句柄，生命周期由操作系统管理，且自带状态（偏移量、锁、关闭标志等）。
- Put 进池后若被其他 goroutine Get 到，可能仍在读写中，导致
read/write on closed file或bad file descriptor - GC 不会回收已关闭但未显式释放的句柄，Pool 也不负责调用
Close() - 多个 goroutine 并发操作同一
*os.File实例，即使加锁也难以保证偏移和缓冲一致性
真正可行的“文件句柄复用”其实是连接池模式
如果你需要减少打开/关闭文件的系统调用开销（比如高频小文件读写），应转向连接池思路：预开一批句柄，按需租借 + 显式归还 + 超时/空闲回收。
- 用
chan *os.File实现简易池：启动时打开 N 个句柄，Get 从 channel 取，Put 回 channel - 必须在 Put 前重置状态：调用
file.Seek(0, io.SeekStart)，清空缓冲区（如bufio.NewReader(file)需重建） - 必须处理异常关闭：Get 后检查
file.Stat()是否返回os.PathError；Put 前确保没被关闭过（可包装一层带 closed 标志的 struct） - 避免长期驻留：设置最大空闲时间，用
time.AfterFunc定期 Close 多余句柄
更推荐的替代方案：内存映射或批量 I/O
高频小文件访问，往往不是句柄开销大，而是系统调用+磁盘寻道成本高。此时 sync.Pool 的适用对象其实是中间缓存结构，而非句柄本身：
- 用
sync.Pool复用*bytes.Buffer或[]byte做读写缓冲，避免每次 malloc - 对固定路径的小文件，改用
mmap（通过golang.org/x/exp/mmap或 syscall.Mmap）一次映射，反复读取无需 reopen - 合并小写操作：攒批写入临时 buffer，再一次性
WriteAt或Write，减少 syscalls
真正要复用句柄，就得自己管生命周期——sync.Pool 不是万能池，它不替你关文件，也不拦你误复用。最容易被忽略的是：哪怕你封装得再严密，只要没强制 Seek 和 Truncate，Get 到的句柄大概率带着上一个用户的读写位置和脏数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
