linux下用getrlimit获取当前进程最大文件描述符数，需调用getrlimit(rlimit_nofile, &rl)并检查返回值，rl.rlim_max为硬限制上限，rl.rlim_cur为实际生效软限制，二者均属进程级限制而非系统全局值。
Linux下用getrlimit查最大文件描述符数
Linux系统中，进程能打开的文件描述符上限由RLIMIT_NOFILE资源限制控制，getrlimit是最直接、最标准的获取方式。它返回的是当前进程的软限制（rlim_cur）和硬限制（rlim_max），通常你关心的是硬限制——即系统允许设到的最高值。
注意：getrlimit查的是**当前进程的限制**，不是整个系统的全局上限；但普通用户进程的硬限制通常等于系统配置的上限（如/proc/sys/fs/file-max），除非被setrlimit主动调低过。
- 必须包含
<sys></sys>头文件 -
rlimit结构体中rlim_max字段才是你要的最大可设值 - 若
getrlimit返回-1，检查errno是否为EPERM（权限不足）或EINVAL（参数非法）
#include <sys>
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
printf("max fd: %ld\n", rl.rlim_max);
}</sys>
macOS上getrlimit行为略有不同
macOS也支持getrlimit，但默认硬限制往往远高于Linux（例如常见为unlimited或一个极大值），且实际生效上限还受kern.maxfiles内核参数约束。仅靠getrlimit可能看不出真实瓶颈。
更稳妥的做法是：先调getrlimit，再尝试读取/proc/sys/fs/file-max（Linux特有）或sysctl kern.maxfiles（macOS可用）。
- macOS没有
/proc/sys/...路径，不能直接cat该文件 - 用
sysctl -n kern.maxfiles命令行可查，C++里需调sysctlbyname("kern.maxfiles", ...) -
sysctlbyname需包含<sys></sys>，且返回值为0才表示成功
为什么不能只看ulimit -n输出？
ulimit -n显示的是当前shell会话的软限制，它可能被用户手动改小（比如ulimit -n 1024），而程序启动后继承的是这个软限制——即使系统硬限制是65536，你的进程也开不了超过1024个fd。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
所以仅靠shell命令判断不可靠，尤其在守护进程、systemd服务或容器环境中，ulimit可能被覆盖或重置。
- systemd服务需显式配置
LimitNOFILE=，否则继承父进程（通常是1024） - Docker容器默认
--ulimit nofile=1024:1024，除非用--ulimit nofile=65536:65536覆盖 - 程序启动后调
getrlimit才能反映真实可用值
跨平台封装时要注意的坑
Windows没有rlimit概念，其句柄限制由_getmaxstdio（C运行时）或进程对象句柄表大小决定，且默认宽松得多。强行统一接口容易误导。
如果写跨平台代码，建议：Linux/macOS走getrlimit + sysctlbyname兜底；Windows直接跳过或返回一个保守估计值（如8192），并加注释说明机制差异。
- 不要在Windows上调
getrlimit——编译不过或链接失败 - 避免用
#ifdef __linux__粗粒度判断，macOS也需要getrlimit - 硬编码
65536作为“最大值”是危险的，某些嵌入式或容器环境可能低至1024
真正可靠的逻辑永远是：运行时查，而不是编译时猜。尤其在云环境或CI/CD流水线中，ulimit和sysctl配置常被动态调整，静态假设很容易出错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
