go进程启动时应调用unix.getrlimit(unix.rlimit_nofile, &rlim)读取/proc/self/limits中真实软限rlim.cur，若低于8192须log.fatal；rlim.cur与rlim.max宜设为相同值（如65536），避免operation not permitted错误。
Go进程启动时如何读取并校验真实fd限制值
别信ulimit -n输出——它查的是当前shell的软限，Go进程实际生效值在启动瞬间就已锁定。容器、systemd或supervisor拉起的服务几乎都不继承它。
最可靠的方式是在main()开头直接调用unix.Getrlimit(unix.RLIMIT_NOFILE, &rlim)（需// +build !windows），取rlim.Cur做判断：
-
rlim.Cur低于8192时，建议log.Fatal("fd soft limit too low")，不等压测崩溃再处理 -
rlim.Cur和rlim.Max最好设为相同值（如65536），避免运行时因软限不足触发降级 - 调用失败报
operation not permitted，通常是因为硬限制没同步提升，先查ulimit -Hn
http.Server默认配置为什么是fd泄漏重灾区
没设超时的HTTP服务，一个慢客户端就能让fd卡在ESTABLISHED或CLOSE_WAIT状态几分钟，too many open files往往最先在这里爆。
必须显式设置三类超时：
-
ReadTimeout和WriteTimeout建议≤30s，防止单请求长期占着fd -
IdleTimeout设为60–120s，比Nginx的keepalive_timeout小10s，避免半开连接堆积 - Go 1.19+可用
MaxConns硬限总连接数，但它不区分活跃/空闲，适合突发压制
os.Open和http.Response.Body漏关fd的典型场景
文件大小不影响fd占用，只影响内存；漏掉Close()是最常见泄漏源，GC不会自动回收fd。
实操要点：
- 所有
os.Open*调用后，强制加defer f.Close()，哪怕只读一次 - 避免循环里反复
os.Open → io.ReadAll → 忘关；改用os.ReadFile（内部自动开闭） -
http.Response.Body必须defer resp.Body.Close()，Client复用连接时尤其容易漏 - 临时文件务必用
os.CreateTemp，业务逻辑结束立即os.Remove，不等GC
容器中ulimit配置为何经常失效
Docker/K8s里securityContext.ulimits或--ulimit参数看似配了，但Go进程仍报错，根本原因是runtime只在启动时读一次/proc/self/limits，后续动态调高它完全感知不到。
验证和修复方式：
- 进容器后执行
ps aux | grep yourapp找到PID，再cat /proc/<pid>/limits</pid>确认是否匹配预期 - 若用
sh -c "exec yourapp"启动，shell会重置限制；改用exec yourapp直接替换PID 1 - initContainer方案要确保它修改的是容器的
/proc/sys/fs/file-max和ulimit，而非仅自己生效
真正难处理的不是“怎么开更多fd”，而是“哪些goroutine正在持有fd却迟迟不释放”——比如阻塞在syscall.Read或卡在os.File.Close的goroutine，得靠pprof抓/debug/pprof/goroutine?debug=2才能定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
