根本原因是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()。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 必须设置 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 或改用 systemd cgroup driver

Go 的 fd 问题从来不是单点配置能解决的——它横跨容器运行时、Linux 内核、Go runtime 初始化时机、HTTP 服务层策略四个层面。最容易被忽略的是：哪怕所有配置都对，只要 Go 进程启动时那个瞬间的 RLIMIT_NOFILE 没达标，后面所有优化都只是延缓崩溃时间。