go启动即报“too many open files”说明系统fd软限制低于最低要求8192，需在main()开头用unix.getrlimit读取/proc/self/limits中rlim.cur校验，而非依赖ulimit -n；容器中须确保--ulimit或securitycontext.ulimits作用于pid 1进程。
Go 启动就报 too many open files，说明进程还没跑起来，系统 fd 软限制就已经低于运行所需最低值——这不是代码漏关的问题，而是启动前环境没对齐。
查清 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做校验，低于 8192 就log.Fatal - 如果
/proc/1/limits里 Soft 值不对，说明 PID 1（即你的 Go 二进制）根本没继承到 ulimit，得检查 K8ssecurityContext.ulimits是否作用于主容器，或 Docker 是否用了--init干扰了信号传递
HTTP Server 默认配置是启动即崩的高危点
没设超时的 http.Server 在启动 accept 阶段就会卡住 fd：一个恶意空连接、一个慢客户端握手未完成，就能让 listener 卡在 accept 系统调用里，fd 持续占用不释放，直到超时（默认 3 分钟）。这比 handler 里漏关更早触发 too many open files。
-
ReadTimeout和WriteTimeout必须显式设（如30 * time.Second），否则单请求可无限期占着 fd -
IdleTimeout设为60–120 * time.Second，比反向代理（如 Nginx）的keepalive_timeout小 10 秒，避免半开连接堆积 - Go 1.19+ 可用
MaxConns硬限总连接数，但它统计的是所有连接（含空闲），适合突发压制，不能替代超时
os.Open / net.Listen 后没 Close 是最常见启动失败原因
不是“并发高才爆”，而是启动阶段反复 os.Open 配置文件、os.CreateTemp 日志目录、net.Listen 多端口监听，只要漏一个 Close()，fd 就永久泄漏。GC 完全不回收 fd，defer 也救不了被 panic 或 os.Exit 跳过的场景。
- 所有
os.Open*调用后必须紧跟defer f.Close()，哪怕只读一次；循环里别用os.Open → io.ReadAll，改用os.ReadFile（内部自动开闭） -
net.Listen是资源型对象，热更新或测试代码里反复Listen却忘了l.Close()，fd 会越积越多；正确做法是全局复用一个 listener，关闭逻辑要加recover防 panic 中断 - 临时文件用
os.CreateTemp，业务逻辑结束立即os.Remove，别等 GC ——/tmp下残留的句柄在重启时仍会计入新进程限制
容器里 ulimit 生效必须盯死 PID 1
runtime 不感知后续 ulimit 变更，容器启动后动态调高 ulimit -n 对已运行的 Go 进程完全无效。initContainer 修改的 /proc/sys/fs/file-max 只影响内核全局，不改变单进程限制；entrypoint 脚本里的 ulimit -n 命令只作用于子 shell，不会透传给 exec ./app。
- Docker 要用
docker run --ulimit nofile=65536:65536，且确保 CMD 是["./app"]而非["sh", "-c", "./app"] - K8s 中
securityContext.ulimits必须写在主容器定义里，并确认ps aux | grep yourapp找到的 PID 确实是 1（cat /proc/1/cmdline验证） - systemd 服务要加
LimitNOFILE=65536到 unit 文件，不能只在ExecStart前加ulimit -n，后者只对 exec 子进程生效
真正难定位的不是“开了多少 fd”，而是“哪些 goroutine 正在持有 fd 却卡在 syscall.Read 或 os.File.Close 上”——这种阻塞态不会出现在 lsof 的文件路径里，得靠 runtime.SetBlockProfileRate(1) + /debug/pprof/goroutine?debug=2 抓堆栈才能看见。
