文件描述符泄露是已耗尽资源的明确信号，根本原因是os.file打开后未关闭，导致“too many open files”、服务拒连、日志写入失败；须用/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 —— 如果一堆 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 —— 必须先判错：if err != nil { return }再defer f.Close()
HTTP 场景下最容易被忽略的 fd 泄漏点
很多人以为 http.Client 是黑盒，其实它底层全是 fd：
-
resp.Body必须显式Close()，哪怕你只读前几个字节。漏掉这句，底层persistConn就不会归还给连接池，fd 一直占着 -
http.Transport.MaxIdleConnsPerHost设得过大，加上resp.Body没关，idle 连接堆积，fd 数直线上升 - 用
io.Copy或io.ReadAll处理响应体后，依然要resp.Body.Close()—— 这两个函数不接管生命周期，只读数据 - 临时文件上传时，
req.MultipartReader()返回的io.Reader底层可能打开临时磁盘文件，务必确保整个请求处理完后清理，不要依赖 GC
真正难排查的不是“哪行没写 Close”，而是“哪条执行路径绕过了 Close”——尤其在 error 分支、panic 恢复、goroutine 异步退出这些边界情况里。监控 fd 总数只是第一步，必须把 os.Open 和 Close 的配对关系，落到每一处错误处理和并发控制的细节里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
