go程序报“too many open files”根本原因是fd未关闭而非并发高，需用lsof或/proc/pid/fd查占用、pprof定位阻塞goroutine，http必须close req.body，禁用sync.pool复用*os.file，超时与连接数限制必不可少。
Go 程序报 too many open files，不是并发太高导致的“开得多”，而是“关得少”——文件描述符（fd）一旦打开没关，就永远卡在进程里，直到程序退出。调大 ulimit 只是拖延崩溃时间，真正要动的是代码里每一处 os.Open、http.Client、net.Listener 的生命周期管理。
怎么快速定位哪段代码在漏关 fd
别靠猜，直接看操作系统真实占用：
-
lsof -p <pid> | wc -l</pid>查当前总 fd 数，对比ulimit -n看是否逼近上限 -
lsof -p <pid> | grep -E '\.(log|tmp|json|db)$'</pid>快速筛出高频路径，比如轮转日志、临时文件残留 -
cat /proc/<pid>/fd | wc -l</pid>更轻量，绕过lsof权限问题 - 启动时加
runtime.SetBlockProfileRate(1)，再访问/debug/pprof/goroutine?debug=2，搜os.File.Close或syscall.Read阻塞的 goroutine —— 它们大概率卡在没 Close 的地方
HTTP Server 场景下哪些资源必须显式 Close
很多人以为 defer conn.Close() 有用，其实完全无效：net/http 底层已接管连接，你 defer 的只是 handler 栈帧里的局部变量。
- 必须调
req.Body.Close()，尤其 POST/PUT 带 body 时，否则底层 TCP 连接无法复用，fd 持续累积 - 用
io.Copy写入本地文件？目标*os.File要Close()；但写入bytes.Buffer或http.ResponseWriter就不用 - 第三方日志库、配置加载器、数据库驱动（如
sql.DB）可能隐式持有了 fd：检查它们是否暴露Close()方法，或是否复用底层文件句柄 -
http.Server必须配ReadTimeout、WriteTimeout、IdleTimeout，Go 1.19+ 还建议加MaxConns硬限总连接数
并发文件操作时为什么不能用 sync.Pool 复用 *os.File
因为 *os.File 包含不可复制的内核 fd 和内部状态（偏移、锁、关闭标记），放进 sync.Pool 再取出时，可能已失效、被其他 goroutine 并发修改，或触发 bad file descriptor。
- 正确做法是控制“打开频率”，而非复用句柄：小文件优先用
os.ReadFile（它内部自动Open+Read+Close） - 大文件流式处理用
bufio.NewReader+ 固定 buffer（如64 * 1024），避免反复分配内存，同时确保每次file.Read后检查err == io.EOF并显式file.Close() - 长期需要读写的文件（如配置、轮转日志目标），用单例 +
sync.RWMutex管理，只在变更时重新Open，旧句柄Close - 临时文件必须用
os.CreateTemp，业务逻辑结束立即os.Remove，别等 GC —— 文件句柄不归 GC 管
要不要调大 ulimit 和 Go 运行时感知上限
可以，但必须同步改两层，否则 Go 的 net.Conn 等底层仍可能因内核限制失败：
- shell 启动前执行
ulimit -n 65536（仅对当前会话生效）；systemd 服务需在[Service]段加LimitNOFILE=65536 - Go 程序启动时（main 函数开头、任何 goroutine 启动前）调用
unix.Setrlimit(unix.RLIMIT_NOFILE, &unix.Rlimit{Max: 65536, Cur: 65536})，让 runtime 知道上限已变 - 验证是否生效：
cat /proc/<pid>/limits | grep "Max open files"</pid>，确认 Max 和 Cur 均为预期值 - 注意：如果
Setrlimit返回operation not permitted，通常是因为硬限制没同步提升，先查ulimit -Hn
最常被忽略的一点：defer f.Close() 在 panic 被 recover 后仍会执行，但如果 recover 后继续运行且没重试逻辑，旧 *os.File 可能被丢弃而新文件又打开，形成隐性累积；更隐蔽的是 for 循环里启动 goroutine 时直接引用循环变量，导致多个 goroutine 共享同一个 *os.File，Close() 被多次调用或漏调 —— 这类 bug 不靠工具根本看不见。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
