直接看/proc/[pid]/fd/数量是否持续上涨，再结合lsof -p [pid]里大量socket:[...]或anon_inode:[eventpoll]，即可确认文件描述符泄漏导致读写超时；出问题时立即执行ls /proc/[pid]/fd/ | wc -l查真实总数，若超ulimit -n软限制（如1024）且非普通fd占比超30%，即证实泄漏。
直接看 /proc/[pid]/fd/ 数量是否持续上涨，再结合 lsof -p [pid] 里大量 socket:[...] 或 anon_inode:[eventpoll]，基本就能确认是文件描述符泄露导致的读写超时——不是网络延迟、不是磁盘慢，是系统没 fd 可分配了。
怎么快速确认 fd 是否真在泄漏
别等服务挂了才查。出问题时立刻执行：
-
ls /proc/<pid>/fd/ | wc -l</pid>—— 这是真实 fd 总数（含 socket/eventpoll），数值超过软限制（ulimit -n）就必然出问题 -
lsof -p <pid> | grep -E 'socket|anon_inode|pipe' | wc -l</pid>—— 看非普通文件类 fd 占比，>30% 就高度可疑 -
cat /proc/<pid>/limits | grep "Max open files"</pid>—— 确认软限制值，比如 1024，而当前/proc/<pid>/fd/</pid>已有 980+，那下次 dial 或 open 就大概率失败
注意：用 lsof -p 统计总数会漏掉很多伪文件，它默认过滤 anon_inode 和 pipe，不能替代 /proc/[pid]/fd/ 直读。
为什么 Read/Write 会突然超时而不是 panic
底层 syscall 失败时，Go 标准库多数会转成 syscall.EBADF 或 syscall.EMFILE，但封装层（如 net.Conn.Read、os.File.Write）常静默转为 io.EOF 或 io.ErrUnexpectedEOF，尤其在 http.Client、websocket、bufio.Scanner 场景下。你看到“timeout”或“connection reset”，实际日志里可能只有 read: connection reset by peer，根本没提 fd。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- NFS/SMB 上更隐蔽：
syscall.ESTALE或syscall.ETIMEDOUT可能被吞掉，最终表现为阻塞数秒后返回空 err -
http.Client.Do在 fd 耗尽时可能卡在 DNS 解析或 dial 阶段，超时时间被完整耗尽，而非提前失败 - 即使你设了
conn.SetReadDeadline，若 fd 已无效，deadline 不生效，调用直接失败
哪些 Go 模块最常触发这类超时
不是所有模块都平等暴露 fd 泄漏。以下场景一旦出问题，超时就是第一症状：
-
golang.org/x/net/websocket（已归档）：每次重连不Close()，旧连接 socket 持续占 fd，新 dial 直接失败，JSON.Receive立即 EOF -
net/http.Server+ 长连接未设IdleTimeout或ReadTimeout：客户端断连后 conn 对象滞留，fd 不释放，堆积到阈值后新请求无法 accept -
os.Open+defer f.Close()在 goroutine 中失效：比如for range files { go func() { f, _ := os.Open(name); defer f.Close(); ... }() }—— 所有 goroutine 共享同一个f变量，close 乱序或遗漏 -
time.AfterFunc/time.Ticker+net.Listener组合：定时器回调里启新 goroutine 监听但没传 cancel，listener.Close() 后 fd 仍残留
特别注意：这些模块本身没错，错在生命周期管理缺失。Go 不会自动关 fd，只靠 defer 或 GC 是幻觉。
修复时最容易忽略的三个点
修完代码跑通不代表问题消失。真正麻烦的是那些“看起来关了，其实没关”的情况：
-
f是 nil 时defer f.Close()panic —— 必须先判 err：if err != nil { return err }; defer f.Close() - recover 后继续执行，旧
*os.File变量被新赋值覆盖，原句柄永久悬空 —— recover 不该掩盖资源清理逻辑 - 临时文件用
os.Create而非os.CreateTemp，且没配defer os.Remove—— 文件删了，fd 还在；GC 不管 fd，只管内存
复杂点永远不在“怎么关”，而在“谁该关、什么时候关、关之前有没有被覆盖”。尤其在多 goroutine + error branch + recover 交织的模块里，defer 的可靠性远低于显式 close 配合 context.Done() 控制流。
