Go进程报“too many open files”根本原因是fd未关干净且启动时限制未对齐，须在main开头用unix.Getrlimit校验/proc/self/limits中rlim.Cur值是否≥8192，强制defer关闭os.File，显式配置http.Server超时，并确保容器或supervisor中ulimit作用于PID 1进程。
Go 进程报 “too many open files”，不是并发太高，而是 fd 没关干净 + 启动时限制没对齐。 单纯调大 ulimit -n 只能延缓崩溃，不能根治。真正要做的，是校验真实限制、堵住泄漏源头、配死超时和硬限——三者缺一不可。
查清 Go 进程当前真实的 fd 限制值
别信 ulimit -n 输出——它查的是 shell 的软限，不是 Go 进程启动时读到的值。容器里尤其容易错判。
- 进容器后执行
cat /proc/$(pidof yourapp)/limits | grep "Max open files"，看软限（第一个数字）是否符合预期 - 在 Go 的
main()开头用unix.Getrlimit(unix.RLIMIT_NOFILE, &rlim)主动读取，取rlim.Cur校验 - 若
rlim.Cur < 8192，直接log.Fatal("fd soft limit too low")，别等运行中崩 - Windows 下不支持
unix包，需加// +build !windows构建约束
堵住最常见 fd 泄漏源：os.Open 和 http.Server
文件大小不影响 fd 占用，只影响内存；漏掉 Close() 是最常见泄漏源，GC 不会自动回收 fd。
- 所有
os.Open/os.Create后必须加defer f.Close()，哪怕只读一次 - 避免循环里反复
os.Open → io.ReadAll → 忘关；改用os.ReadFile（内部自动开闭） - 临时文件务必用
os.CreateTemp，业务逻辑结束立即os.Remove -
http.Server默认不限连接、不设超时，一个慢连接就能卡住 fd 几分钟——必须显式配ReadTimeout、WriteTimeout、IdleTimeout
在 Supervisor 或容器中正确生效 ulimit
Supervisor 不继承 /etc/security/limits.conf，K8s/Docker 动态调高 ulimit 对已启动的 Go 进程完全无效。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Supervisor：必须在
/etc/supervisor/supervisord.conf的[supervisord]节下设minfds = 100000，改完要sudo systemctl restart supervisor - Docker：用
docker run --ulimit nofile=65536:65536，确保 entrypoint 没有ulimit -n覆盖 - K8s：
securityContext.ulimits必须作用于 PID 1 进程，检查cat /proc/1/limits确认是否生效 - 验证方式统一：进容器后
cat /proc/$(pgrep -f "your-go-binary")/limits | grep "Max open files"
定位难发现的阻塞型 fd 持有
真正难处理的不是“怎么开更多 fd”，而是“哪些 goroutine 正在持有 fd 却迟迟不释放”——比如卡在 os.File.Close 或 syscall.Read 的协程。
- 用
lsof -p $(pidof yourapp)查当前打开的 fd 数量和类型 - 启用
runtime.SetBlockProfileRate(1)，访问/debug/pprof/goroutine?debug=2抓阻塞 goroutine - 重点关注停在
os.File.Close、net.(*conn).read、http.(*persistConn).roundTrip的协程 - HTTP 出站调用务必复用
&http.Client{Transport: &http.Transport{...}}，否则底层连接池不会释放 fd
fd 限制问题最棘手的地方在于：它不报错在代码里，而是在系统层面静默失败——accept4: too many open files、connect: no such file or directory、甚至 DNS 解析失败，都可能是 fd 耗尽的间接表现。校验、关闭、超时、硬限，四步缺一不可；任何一步跳过，都只是把崩溃时间往后推几天而已。
