ulimit -n 设置后程序仍报“too many open files”是因为该命令仅影响当前shell及其子进程且不持久；systemd服务、Docker容器等绕过此限制，需分别在service文件中配置LimitNOFILE、通过docker run --ulimit或修改/etc/security/limits.conf（并确保PAM启用）来生效。
ulimit -n 设置后为什么程序还是报 too many open files
因为 ulimit -n 只影响当前 shell 及其子进程，且不持久；服务进程（如 systemd 启动的 daemon）通常绕过用户 shell 的限制，走自己的资源控制路径。
- 交互式终端里执行
ulimit -n 65536，再./server启动——有效 - 用
systemctl start myapp启动——完全无视你刚才设的ulimit - 某些容器环境（如 Docker）默认限制为 1024，
ulimit命令在容器内执行也无效，得从宿主机或docker run --ulimit控制
systemd 服务中正确配置文件句柄数
必须在 service unit 文件里显式声明，不能依赖全局 ulimit 或登录 shell 配置。
- 编辑
/etc/systemd/system/myapp.service，在[Service]段下添加：LimitNOFILE=65536<br>LimitNOFILESoft=65536
- 注意：只写
LimitNOFILE不够，某些旧版 systemd 要求同时设置软硬限；若省略LimitNOFILESoft，可能 fallback 到系统默认软限（通常是 1024） - 改完必须运行
systemctl daemon-reload，再systemctl restart myapp，直接kill -s SIGUSR2之类不会重载限制 - 验证是否生效：
cat /proc/$(pidof myapp)/limits | grep "Max open files"，看输出的 soft/hard 值
/etc/security/limits.conf 配置失效的常见原因
这个文件只对 PAM 登录会话生效（比如 ssh、console login），且要求应用通过 login shell 启动；绝大多数后台服务、cron job、GUI 应用都不走这条路。
- 配置示例（对用户
deploy）：deploy soft nofile 65536<br>deploy hard nofile 65536
- 必须确保系统启用了 pam_limits.so：检查
/etc/pam.d/sshd或/etc/pam.d/common-session是否含session required pam_limits.so - Ubuntu 22.04+ 默认禁用 limits.conf 对 systemd 用户会话的支持，即使配置了也不会被读取；此时应优先用 systemd user unit 的
DefaultLimitNOFILE - 如果用
sudo -u deploy ./app启动，sudo默认不继承登录会话的 limits，需加-i参数模拟登录 shell
Go/Python/Node.js 程序里主动检查和适配句柄限制
运行时无法突破系统限制，但可以提前发现并友好提示，避免等到 open: too many open files 才崩溃。
- Go 中可用
unix.Getrlimit(unix.RLIMIT_NOFILE, &r)读取当前软限，若低于预期值（如 - Python 可调
resource.getrlimit(resource.RLIMIT_NOFILE)，配合atexit或启动时校验 - Node.js 没有内置 API 直接读 limit，但可通过
fs.openSync('/dev/null')尝试打开再 close，结合process.maxOpenFiles（仅部分版本支持）粗略估算；更可靠的是解析/proc/self/limits - 注意：硬限（hard limit）不可提升，除非 root；软限（soft limit）可由进程自行调高，但不能超过硬限 —— 所以检查时重点看软限是否足够
