go程序报“too many open files”根本原因是fd未及时关闭且启动时软限制过低（常为1024），需用unix.getrlimit校验/proc/self/limits中rlim.cur值，设read/write/idletimeout、显式关闭req.body、避免goroutine阻塞在syscall.read。
Go 程序报 too many open files，不是 Go 语言本身设了上限，而是进程启动时继承的文件描述符软限制太低（常为 1024），且代码中存在未关闭的 os.File、http.Response.Body 或长连接未释放——调大限制只是延缓崩溃，不关 fd 才是根本原因。
查清当前进程真实的 fd 限制值
别信 ulimit -n 输出：它只反映当前 shell 的软限，Go 进程实际生效值在启动时就已锁定。容器、systemd、supervisor 启动的服务几乎都不继承它。
- 进生产环境后，立刻执行
cat /proc/$(pidof yourapp)/limits | grep "Max open files"，看两列数字（Soft / Hard）是否达标 - Go 程序里用
unix.Getrlimit(unix.RLIMIT_NOFILE, &rlim)（需// +build !windows）读取内核真实值，取rlim.Cur校验 - 若
rlim.Cur ，直接 <code>log.Fatal("fd soft limit too low")，别等压测时崩
Go 程序启动时必须主动调用 syscall.Setrlimit
systemd 配了 LimitNOFILE、ulimit 改了、/etc/security/limits.conf 加了，都不保证 Go 进程能拿到——它只在 main() 开头读一次内核限制，之后再改无效。
- 必须在任何 goroutine 启动前、任何
net.Listen或http.Server初始化前调用 -
Cur和Max建议设为相同值（如 65536），避免运行时因软限不足触发降级 - 调用失败（
operation not permitted）通常是因为硬限制没同步提升，先查ulimit -Hn
http.Server 和 http.Client 是 fd 泄漏重灾区
HTTP 服务默认不设防，一个慢客户端就能让 fd 卡在 ESTABLISHED 或 CLOSE_WAIT 几分钟；Client 默认复用连接，但后端不响应 Connection: close 就会持续堆积。
-
http.Server必须配：ReadTimeout、WriteTimeout（≤30s）、IdleTimeout（60–120s），Go 1.19+ 加MaxConns硬限总连接数 - Handler 里所有
req.Body必须显式req.Body.Close()，尤其 POST/PUT 带 body 场景，否则底层 TCP 连接无法复用 -
http.Client要自定义Transport：MaxIdleConns: 100、MaxIdleConnsPerHost: 100、IdleConnTimeout: 30 * time.Second
哪些地方最容易漏关 fd？
fd 泄漏往往藏在“看起来不用关”的地方，比如日志写入、配置加载、临时文件、第三方库内部句柄——GC 不回收 fd，靠 defer 也兜不住所有场景。
-
os.Open/os.Create后必须立刻defer f.Close()；循环里反复打开，优先换用os.ReadFile - 用
io.Copy写入*os.File？目标文件必须Close()；写入bytes.Buffer或http.ResponseWriter就不用 - 第三方库（如日志、DB 驱动、配置热加载器）可能隐式持有 fd：检查是否暴露
Close()方法，或是否复用底层句柄 - WebSocket、TCP 长连接服务中，
listener.Accept()后起 goroutine 处理，结束时必须显式conn.Close()，defer conn.Close()在 HTTP 场景下无效
真正难定位的不是“开了多少 fd”，而是“哪些 goroutine 正卡在 syscall.Read 或 os.File.Close 上迟迟不返回”——这得靠 runtime.SetBlockProfileRate(1) + /debug/pprof/goroutine?debug=2 抓阻塞栈，而不是靠猜。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
