Go进程报“too many open files”本质是未及时关闭文件、未限制并发及系统fd配置不当；需在启动前固定系统限制，用unix.Getrlimit读取/proc/pid/limits中真实Soft值校验。
go 进程报 too many open files，不是“开了太多文件”，而是“该关的没关 + 该限的没限 + 该调的没调对”。系统 fd 限制必须在 go 启动前固定，且 runtime 不会感知后续变更。
查当前进程真实 fd 限制，别信 ulimit -n
ulimit -n 查的是 shell 的软限，不是 Go 进程实际生效值。容器里看到 1048576，但 Go 还是报错，大概率是它启动时读的 /proc/self/limits 仍是旧值。
- 进容器后执行
cat /proc/$(pidof yourapp)/limits | grep "Max open files"，确认Limit列的Soft值 - Go 程序中用
unix.Getrlimit(unix.RLIMIT_NOFILE, &rlim)（需// +build !windows）直接读内核值，取rlim.Cur比字符串解析更稳 - 建议在
main()开头校验：if rlim.Cur
http.Server 是 fd 泄漏高发区，必须配超时和连接数
默认 http.Server 对连接不设防：慢客户端、代理 keep-alive 失配、空闲连接堆积，都会让 fd 卡在 ESTABLISHED 或 CLOSE_WAIT 状态，直到 3 分钟超时才释放。
-
ReadTimeout和WriteTimeout必须设（如30 * time.Second），防止单请求长期占着 fd -
IdleTimeout推荐60–120 * time.Second，比 Nginx 的keepalive_timeout小 10 秒，避免“一方已关、另一方还在等” - Go 1.19+ 可用
MaxConns硬限总连接数，注意它不区分活跃/空闲，适合突发压制
os.Open / http.Client 底层复用都可能漏关 fd
os.Open 后漏掉 defer f.Close()、http.Response.Body 没关、甚至 http.Client 复用时底层连接未释放，都会导致 fd 持续增长。lsof 能帮你定位：
- 用
lsof -p <pid> | wc -l</pid>看当前 fd 总数 - 快速筛文件类 fd：
lsof -p <pid> | grep -E '\.(txt|log|json|tmp)$'</pid> - 抓阻塞 goroutine：
runtime.SetBlockProfileRate(1)+/debug/pprof/goroutine?debug=2，重点看停在os.File.Close或syscall.Read的协程
容器里 ulimit 配置容易失效，得盯住 PID 1
K8s 的 securityContext.ulimits 或 docker run --ulimit 不一定生效到 Go 主进程——因为容器启动时 init 进程（PID 1）可能没继承限制，或被 entrypoint 覆盖。
- 检查
cat /proc/1/limits，确认 PID 1 的 fd 限制是否符合预期 - 若用
sh -c "exec yourapp"启动，shell 会重置限制；改用exec yourapp直接替换 PID 1 - initContainer 方案要确保它修改的是容器的
/proc/sys/fs/file-max和ulimit，而非仅自己生效
fd 限制问题最棘手的点在于：它不报错在代码里，而是在系统层面静默失败；no such host、connection refused 都可能是 fd 耗尽的伪装。别等压测崩了再查，从 main() 开头校验、每个 Open 配 defer Close()、每个 http.Server 配超时开始，才是稳住百万并发的第一步。
