Go启动即报too many open files，说明系统fd软限制低于8192，需在main()开头用unix.Getrlimit校验/proc/self/limits中rlim.Cur值，容器中须确保--ulimit或securityContext.ulimits作用于PID 1进程，并同步调高内核fs.file-max。
go 启动即报 too many open files，说明进程还没执行到业务逻辑，系统 fd 软限制就已低于 go runtime 最低要求（8192）。这不是代码漏关的问题，而是启动前环境没对齐——内核参数、用户限制、容器配置、go 自身校验四者必须闭环。
查清当前 Go 进程真实生效的 fd 限制值
别信 ulimit -n 输出，它只反映当前 shell 的软限；Go runtime 启动时读的是 /proc/self/limits，且只读一次。容器中尤其容易错判：你看到 docker run --ulimit nofile=65536:65536，但若 entrypoint 是 sh -c "exec ./app"，shell 会重置限制，Go 实际拿到的还是默认 1024。
- 进容器后执行
cat /proc/$(pidof yourapp)/limits | grep "Max open files"，看 Soft 列数值 - 在
main()开头加unix.Getrlimit(unix.RLIMIT_NOFILE, &rlim)（需// +build !windows），用rlim.Cur做校验 - 若
rlim.Cur < 8192，直接log.Fatal("fd soft limit too low")，别等运行中崩
Linux 内核级 fd 上限必须先调高
/proc/sys/fs/file-max 是所有进程能打开 fd 的总天花板，它必须 ≥ 单个 Go 进程所需上限 × 预期并发进程数。设得太低，后续所有调优都白搭；设得太高（如超内存 10%），可能引发 OOM。
- 临时生效（验证用）：
sysctl -w fs.file-max=200000 - 永久生效：编辑
/etc/sysctl.conf，追加fs.file-max = 200000，再执行sysctl -p - 估算推荐值：
grep MemTotal /proc/meminfo | awk '{print int($2/10)}'（单位 KB → 约等于建议 file-max）
Docker/K8s 中 ulimit 必须作用于 PID 1 进程
Go runtime 只在启动瞬间读取 fd 限制，后续容器动态调高 ulimit 它完全感知不到。K8s 的 securityContext.ulimits 或 Docker 的 --ulimit 必须确保作用于主容器的 PID 1（即你的 Go 二进制），而非被 init 进程或 shell 覆盖。
- 验证方式：进容器后
ps aux | grep yourapp找到 PID，再cat /proc/<pid>/limits</pid>看是否匹配预期 - 避免
sh -c "exec ./app"启动方式，改用exec ./app直接替换 PID 1 - 若用
--init，确认 init 进程是否透传了 ulimit（部分 init 不支持）
Go 代码里必须主动关闭资源，不能依赖 GC
GC 完全不回收 fd，defer 也救不了被 panic 或 os.Exit 跳过的场景。最常见泄漏源是启动阶段反复 os.Open 配置文件、os.CreateTemp 日志目录、net.Listen 多端口监听——只要漏一个 Close()，fd 就永久卡住。
- 所有
os.Open*调用后必须紧跟defer f.Close()，哪怕只读一次 - 循环里别用
os.Open → io.ReadAll，改用os.ReadFile（内部自动开闭） -
net.Listen是资源型对象，热更新或测试代码里反复Listen却忘了l.Close()，fd 会越积越多
真正难处理的不是“怎么开更多 fd”，而是“哪些 goroutine 正在持有 fd 却迟迟不释放”——比如阻塞在 syscall.Read 或卡在 os.File.Close 的 goroutine，得靠 runtime.SetBlockProfileRate(1) + /debug/pprof/goroutine?debug=2 才能定位。
