根本原因是go程序启动时只读取一次/proc/self/limits，后续容器动态调高ulimit不会被感知；且http.server默认不限制连接数和超时，易导致fd耗尽。
容器里 ulimit -n 显示 1048576，但 Go 程序还是报 too many open files
根本原因不是容器没设限，而是 Go runtime 启动时只读了一次 /proc/self/limits，之后即使容器运行中动态调高限制（比如用 docker update --ulimit nofile=65536:65536），Go 不会重新加载。更关键的是：Go 的 net/http.Server 默认用 runtime.GOMAXPROCS 控制的 goroutine 数量做连接并发上限，但底层文件描述符分配不受此控制——它直通系统 open()，绕过 Go 自己的调度器。
- 启动前必须固定好
ulimit -n，Go 进程不会感知后续变更 - 检查方式不是看容器启动参数，而是进容器执行
cat /proc/$(pidof yourapp)/limits | grep "Max open files" - Docker/K8s 中若用
initContainer或securityContext配ulimit，要确认是否真正生效到主容器进程的 PID 1 上下文
Go 程序启动时如何安全获取并验证当前 fd 限制
别依赖 ulimit -n 命令输出——它查的是 shell 的限制，不是当前进程的。Go 里最可靠的方式是读取 /proc/self/limits 并解析，或者直接调用 unix.Getrlimit(unix.RLIMIT_NOFILE, &rlim)（需引入 golang.org/x/sys/unix）。
- 用
unix.Getrlimit能拿到rlim.Cur（软限）和rlim.Max（硬限），比字符串解析更稳 - 建议在
main()开头就校验，不满足最低要求（如rlim.Cur ）直接 <code>log.Fatal，避免后期随机报错 - 注意：Windows 不支持
unix包，交叉编译或跨平台部署时要加// +build !windows构建约束
http.Server 没配 MaxConns 和 IdleTimeout 是 fd 泄漏重灾区
默认情况下 http.Server 对连接数、空闲时间完全不设防。一个慢客户端持续保持连接、或前端代理没正确复用连接，就会让 fd 卡在 ESTABLISHED 或 CLOSE_WAIT 状态，直到超时（默认 3 分钟）才释放。而 Go 的 net.Conn 关闭不等于 fd 立即归还——得等 GC 回收或显式 Close()。
- 必须设置
ReadTimeout和WriteTimeout（哪怕只是 30 秒），防止单请求长期占着 fd -
IdleTimeout推荐设为 60–120 秒，比反向代理（如 Nginx）的keepalive_timeout小 10 秒，避免“一方已关、另一方还在等” -
MaxConns（Go 1.19+）可硬限并发连接总数，但要注意它不区分活跃/空闲，适合突发流量压制
K8s Pod 中 securityContext 的 ulimit 配置为什么经常失效
因为 K8s 本身不原生支持 ulimit 设置，主流方案是靠容器运行时（如 containerd）或 init 容器注入。常见失效点在于：配置写对了位置，但没覆盖到实际运行 Go 二进制的用户上下文。
立即学习“go语言免费学习笔记（深入）”；
- 如果 Go 程序以非 root 用户运行（推荐），
securityContext.runAsUser必须和ulimit初始化命令的执行用户一致，否则ulimit -n在 init 容器里设了，切到普通用户后又回落到默认值（通常是 1024） - 用
initContainer设 ulimit 时，命令必须是sh -c 'ulimit -n 65536 && exec sleep infinity'，不能只写ulimit -n 65536（它只影响当前 shell） - containerd 的
config.toml中若配了[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]下的NoNewPrivileges = true，可能阻止 ulimit 提升，得同步开privileged: true或改用systemdcgroup driver
RLIMIT_NOFILE 没达标，后面所有优化都只是延缓崩溃时间。 
