“too many open files”根本原因是文件描述符泄漏且进程启动时fd限制未对齐；需精准定位泄漏点、强制关闭req.body和os.file等关键资源、配置http超时与连接池，而非仅调大ulimit。
Go 本身不限制并发连接数，报 “too many open files” 是操作系统级限制被突破——根本原因不是开得多，而是关得少。优化核心是：精准定位泄漏点、强制关闭关键资源、合理配置连接生命周期、避免错误复用句柄。
快速定位 fd 泄漏源头
别猜代码，直接看进程真实状态：
- 查总数：
lsof -p <pid> | wc -l</pid>，对比ulimit -n判断是否逼近上限 - 筛文件类 fd：
lsof -p <pid> | grep -E '\.(log|json|tmp|db|conf)$'</pid>，重点关注轮转日志、临时配置、未清理的 db 文件 - 轻量验证：
cat /proc/<pid>/fd | wc -l</pid>（无权限依赖，比 lsof 更快） - 结合 pprof 找阻塞点：启动时加
runtime.SetBlockProfileRate(1)，访问/debug/pprof/goroutine?debug=2，重点过滤含os.File.Close或syscall.Read的 goroutine —— 它们大概率卡在没 Close 的地方
HTTP Server 场景必须关的三类 fd
net/http 底层自动管理连接，但你显式打开的资源必须自己负责：
- req.Body.Close()：POST/PUT 带 body 时必调，否则底层 TCP 连接无法复用，fd 持续累积
-
显式打开的文件：如用
os.Open读配置、os.Create写日志、io.Copy(dst, src)中的dst *os.File，全部要配defer f.Close() -
第三方组件隐式句柄：检查日志库（如 zap 的 file sink）、数据库驱动（
sql.DB的底层连接池）、配置加载器是否暴露Close()方法；没提供就需确认其是否复用句柄或有内部回收机制
连接池与超时配置是 fd 控制的关键杠杆
不设超时的 HTTP Server 或 Client，会把 fd 当“长期工”用，最终堆满：
- Server 端必须显式设置四项：
ReadTimeout: 15 * time.Second（防上传卡住）WriteTimeout: 15 * time.Second（防响应生成慢）IdleTimeout: 60 * time.Second（最核心，空闲连接强制断开）MaxHeaderBytes: 64 （防 header DoS 占内存） - Client 端禁用默认 Transport 的“失控复用”：
自定义http.Transport，设MaxIdleConns: 100、MaxIdleConnsPerHost: 100、IdleConnTimeout: 30 * time.Second，并确保业务逻辑中不用完不丢弃 client 实例
别踩这些常见陷阱
有些做法看似优化，实则埋雷：
-
sync.Pool 复用 *os.File 或 net.Conn？不行。 文件句柄和 socket fd 是内核资源，含不可复制的 fd 字段、偏移、锁等状态，Pool Put/Get 后极易触发
bad file descriptor或数据错乱 -
defer conn.Close() 在 HTTP handler 里？无效。
net/http已接管连接生命周期，你 defer 的只是栈变量；真正要关的是req.Body和你手动打开的其他资源 -
只调大 ulimit 就完事？掩盖问题。 必须同步让 Go runtime 感知新上限：
启动前 shell 执行ulimit -n 65536（仅当前进程有效）
Go 程序内调用unix.Setrlimit(unix.RLIMIT_NOFILE, &unix.Rlimit{Cur: 65536, Max: 65536})（需导入golang.org/x/sys/unix）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
