必须同时设置软限和硬限，如docker run --ulimit nofile=65536:65536，并配置daemon.json统一兜底，同步调高宿主机fs.file-max及limits.conf，最后通过ulimit和/proc/1/limits验证三处数值一致。
限制容器进程最大打开文件数，本质是控制文件描述符（fd）用量，防止因 fd 耗尽引发系统级连锁故障——比如 nginx 拒绝新连接、java 应用抛 java.io.ioexception: too many open files、甚至触发内核级资源争抢，拖慢整个宿主机。这不是“锦上添花”，而是高并发场景下的生存底线。
为什么 fd 限制直接影响宿主机稳定？
每个 TCP 连接、日志句柄、配置文件读取都占至少 1 个 fd。默认 1024 的限制，在真实业务中几秒就打满。一旦容器内进程反复 open 文件却未 close，fd 泄漏会快速累积。当大量容器同时突破限制，宿主机的全局 fd 表（由 fs.file-max 控制）被撑满，新进程无法启动、sshd 可能失联、dockerd 自身调度卡顿——稳定性直接崩塌。
必须同时设软限和硬限
只设软限（如 --ulimit nofile=65536）不够。软限可被应用运行时动态调低，但无法超过硬限；而硬限若没显式指定，常卡在极低值（如 1024），导致 Java NIO 或 Node.js cluster 模式扩容失败。生产环境务必明确双设：
docker run --ulimit nofile=65536:65536 nginx- docker-compose.yml 中写全：
ulimits: nofile: soft: 65536 hard: 65536
宿主机 daemon 级统一兜底
单个容器逐个配容易遗漏。更稳妥的方式是提升 Docker 守护进程自身上限，让所有新建容器默认继承高 fd 值：
- 编辑
/etc/docker/daemon.json，加入：{ "default-ulimits": { "nofile": { "Name": "nofile", "Hard": 65536, "Soft": 65536 } } } - 重启守护进程：
systemctl restart docker
别忘了宿主机系统层的配合
Docker 容器的 fd 上限再高，也受限于宿主机内核总容量。需同步检查并调整：
- 查当前全局上限：
cat /proc/sys/fs/file-max - 临时提高（重启失效）：
sysctl -w fs.file-max=2097152 - 永久生效：在
/etc/sysctl.conf中追加fs.file-max = 2097152 - 确认用户级限制没拖后腿：
/etc/security/limits.conf中补上：* soft nofile 65536 * hard nofile 65536
验证是否真正生效
光配置不验证等于没做。进容器执行三步检查：
-
ulimit -n→ 应返回 65536（软限） -
ulimit -Hn→ 应返回 65536（硬限） -
cat /proc/1/limits | grep "Max open files"→ 显示两列数字均为 65536
