直接统计/proc/[pid]/fd/目录条目数是最轻量方式：ls -l /proc/[pid]/fd/ | wc -l得总数，再ls -l /proc/[pid]/fd/ 2>/dev/null | grep -e 'reg|socket|pipe' | head -15查前15项类型与路径，可快速定位泄漏源头。
怎么查当前进程开了多少 fd
别依赖 lsof，生产环境优先读 /proc/<pid>/fd/</pid>。用 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.Watcher 实例未 Close。
为什么 defer f.Close() 经常失效
defer 不是保险丝，它只在函数正常返回时触发。以下场景会让它彻底失能：
- goroutine 永久挂起：比如在 handler 里启 goroutine 去读文件，但 channel 没人收、
select没default，这个 goroutine 就卡住不退出，defer永远不跑 -
panic后被recover且继续执行，旧*os.File变量被覆盖，句柄悬空 - 循环变量误用：
for _, name := 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 err }
如何定位具体哪段代码漏关了文件
光看 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 的路径分支。
监控 fd 数量变化比等报错更有效
等 too many open files 报错才行动，已经晚了。应该把 fd 数量作为核心指标持续采集：
直接读 /proc/<pid>/fd/</pid> 目录条目数，每 10 秒采一次，画趋势图；对比 ulimit -n 设置值，当达到 80% 就告警。
容器环境优先读 cgroup 文件：/sys/fs/cgroup/memory/docker/<container_id>/memory.current</container_id> 和 /sys/fs/cgroup/cpu/docker/<container_id>/cpuacct.usage</container_id>，它们比调 Docker API 更稳定、无单点故障风险。
关键点：所有 os.Open、net.Listen、os.Pipe 调用，必须确保配对 Close；HTTP 客户端要设 http.DefaultTransport.MaxIdleConnsPerHost，数据库连接池必须调 sql.DB.SetMaxOpenConns —— 这些不是可选项，是资源守门员。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
