确认是文件句柄泄漏而非其他问题：看到“too many open files”、新HTTP连接被拒、日志写不进磁盘，基本就是句柄耗尽；先用ulimit -n查进程上限，再用ls -l /proc//fd/ | wc -l看实际打开数，接近或超限即坐实，高频重复路径如/tmp/xxx.log或/var/log/app/*.log为关键线索。
怎么确认是文件句柄泄漏而不是其他问题
看到 too many open files、新 HTTP 连接被拒、日志写不进磁盘，基本就是文件句柄耗尽了——不是“可能”，而是已经满了。别急着查代码，先看系统层面是否真满：
-
ulimit -n查当前进程允许的最大 fd 数（常见默认 1024） -
ls -l /proc/看实际打开数，接近或超过 ulimit 就坐实了/fd/ | wc -l -
ls -l /proc/找高频重复路径，比如一堆/fd/ 2>/dev/null | grep -E 'REG|socket' | head -10 /tmp/xxx.log或/var/log/app/*.log
如果发现大量 socket:[...] 或 anon_inode:[eventpoll]，那更可能是 http.Client 或 fsnotify 没关，不是文件问题。
为什么 defer f.Close() 有时根本没生效
defer 不是魔法，它只在函数 return 时执行。很多场景下函数压根不 return，defer 就永远不会跑：
- goroutine 启动后挂起：比如
go func() { f, _ := os.Open(p); defer f.Close(); scanner.Scan() }，但没人收 channel，goroutine 永不退出 - panic 后 recover 且继续执行：旧
*os.File变量被覆盖，新打开的文件又没关，旧句柄悬空 - for range 中闭包捕获变量：
for _, p := range paths { go func() { f, _ := os.Open(p); defer f.Close() }() }，所有 goroutine 共享最后一个p，部分f根本没被关 -
f是 nil：os.Open失败返回nil, err，此时defer f.Close()会 panic
如何安全地跨函数传递并关闭文件
当文件打开和读取逻辑分离（比如封装成 Scanner、Writer），不能靠 defer 自动关——因为函数一返回就关了，后续读写直接失败。必须显式管理生命周期：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用结构体封装：
FileScanner类型里存*os.File和*bufio.Scanner，提供Close()方法，调用方负责最后调用 - 返回清理函数：
func OpenFile(path string) (*os.File, func(), error)，第二项是闭包func() { f.Close() }，由调用方 defer 调用 - 避免 sync.Pool 复用
*os.File：文件句柄是 OS 资源，Pool 无法保证 Close 行为，反而增加泄漏风险
示例关键点：Close() 必须判空：if fs.File != nil { fs.File.Close() }；且只能调一次，重复调会返回 io.ErrClosed。
生产环境怎么快速定位哪段代码漏关了
光看 fd 列表不够，得知道谁 hold 着它。两个手段必须配合用：
- 启动时加
runtime.SetBlockProfileRate(1)，然后访问/debug/pprof/goroutine?debug=2，搜索os.File.Close或syscall.Read—— 如果一堆 goroutine 卡在syscall.Read，说明文件根本没关；卡在os.File.Close，可能是底层锁住或 NFS 异常 - 在
os.Open后立刻打日志：log.Printf("opened %s at %s", path, debug.Stack())，再在defer f.Close()前也打一行，对比就能看出哪些路径分支没走到 Close
注意：pprof 的 goroutine 堆栈要重点看末尾几行，停在 chan receive 或 semacquire 的，大概率是 goroutine 泄露，不是文件句柄问题——得换方向查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
