文件句柄泄漏是系统资源已耗尽的明确信号，表现为“too many open files”、新连接被拒、日志写入失败；根本原因是os.file打开后未关闭，须通过/proc//fd查总数与分布，配合pprof定位阻塞goroutine，并严守错误分支和并发场景下的close配对。
文件句柄泄漏不是“可能出问题”，而是系统资源已耗尽的明确信号——too many open files、新连接被拒、日志写不进磁盘，都是它在敲门。根本原因从来不是并发高，而是某个 os.File 打开后没关，且泄漏会随时间累积，直到进程被系统掐断。
查当前进程 fd 总数和分布
别猜路径，先看总数和类型分布。生产环境不一定装 lsof，优先用 /proc 直接读：
-
ls -l /proc/<pid>/fd/ | wc -l</pid>—— 注意结果含符号链接，实际数量略低，但趋势可靠 -
ls -l /proc/<pid>/fd/ 2>/dev/null | grep -E 'REG|socket|pipe' | head -15</pid>—— 看前 15 个打开项类型和路径，高频重复的/tmp/xxx或/var/log/xxx.log就是重点怀疑对象 - 大量
anon_inode:[eventpoll]或socket:[]？说明可能是http.Client连接池或fsnotify实例没释放
定位具体哪段代码漏关了文件
光看 fd 列表不够，得知道谁在 hold 它。两种方式配合用：
- 启动时加
runtime.SetBlockProfileRate(1)，然后访问/debug/pprof/goroutine?debug=2，搜索os.File.Close或syscall.Read阻塞的 goroutine：
— 如果一堆卡在os.File.Close，说明 Close 被调用了但底层没返回（比如文件正被其他进程锁住）
— 如果卡在syscall.Read，说明文件根本没关，还在等 IO - 对疑似模块加日志：在
os.Open后立刻打一行log.Printf("opened %s at %s", path, debug.Stack())，再配合defer前加日志，能快速圈定未执行Close()的路径分支
defer f.Close() 为什么有时等于没写
defer 只保证函数返回时执行，而很多场景下函数根本不会返回：
- goroutine 挂起：比如 handler 里启了个 goroutine 去读文件，但 channel 没人收、
select没default，这个 goroutine 永远不退出，defer就永远不会触发 -
recover后丢弃文件：panic 被捕获后继续跑逻辑，旧*os.File变量被覆盖，新文件又打开，旧句柄就悬空了 - 循环变量误用：在
for range files中直接go func() { f, _ := os.Open(name); defer f.Close() }()，所有 goroutine 共享同一个name变量，最终可能多个 goroutine 尝试关同一个f，或某个f根本没被关 -
f是nil：os.Open失败时返回nil, err，此时defer f.Close()会 panic
批量文件处理时怎么避免高频 Open/Close
不是靠复用 *os.File（sync.Pool 不适用），而是减少打开次数：
- 小文件用
os.ReadFile：它内部自动Open+Read+Close，语义清晰且无泄漏风险 - 大文件流式处理用
bufio.NewReader+ 固定 buffer（如 4KB），避免反复分配内存；同时确保每次file.Read后检查err == io.EOF并显式file.Close() - 长期需要读写的文件（如配置、轮转日志目标），用单例 +
sync.RWMutex管理，只在变更时重新Open，旧句柄Close - 临时文件必须用
os.CreateTemp，业务逻辑结束立即os.Remove，别等 GC —— 文件句柄不归 GC 管
真正麻烦的不是发现泄漏，而是泄漏藏在 defer 之后、recover 中间、for 循环闭包里——这些地方日志打不到、pprof 看不见、测试压不出来，只能靠对每处 Open 都问一句：“它在哪关？”
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
