Linux下用getrlimit获取RLIMIT_NOFILE可得进程软硬限制，软限制（rlim_cur）为实际生效值，硬限制（rlim_max）为其上限；macOS行为类似但默认值更保守；Windows无等价机制。
Linux下用getrlimit查进程最大文件描述符数
Linux里“句柄”对应的是文件描述符（file descriptor），单个进程的上限由RLIMIT_NOFILE控制，不是全局固定值，而是每个进程独立继承的资源限制。
直接调用getrlimit即可获取当前进程的软限制（soft limit）和硬限制（hard limit）：
#include <sys/resource.h>
#include <iostream>
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
std::cout << "soft: " << rl.rlim_cur << ", hard: " << rl.rlim_max << "\n";
}
-
rl.rlim_cur是当前生效的上限，程序实际能打开的最大fd数（比如open()失败前最多到这个值） -
rl.rlim_max是管理员或父进程允许提升到的最高值，普通进程只能通过setrlimit将其设为≤该值 - 若
rl.rlim_cur为RLIM_INFINITY（通常是0x7fffffffffffffff），表示无硬性限制，但受内核参数/proc/sys/fs/nr_open制约
macOS行为与Linux基本一致但有细微差异
macOS也支持getrlimit(RLIMIT_NOFILE, ...)，语义相同，但默认硬限制通常更低（如10240），且RLIM_INFINITY含义更保守——它可能被内核截断为实际可分配的最大fd数。
验证方式完全一样，但要注意：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 启动终端时shell可能已调用
setrlimit降低了限制，所以即使系统级配置宽松，你的进程也可能继承一个较小的rlim_cur - macOS不提供
/proc接口，无法像Linux那样查/proc/sys/fs/nr_open，需依赖sysctl kern.maxfilesperproc - 某些版本对
rl.rlim_max返回值做归一化处理，不一定反映真实上限，建议以rl.rlim_cur为准
Windows没有等价的“进程级句柄总数限制”概念
Windows中没有类似RLIMIT_NOFILE的统一句柄计数限制。每个进程默认有约16,384个句柄槽（handle table entries），但实际可用数受以下因素动态影响：
- 进程的
Job Object是否设置了LimitFlags | JOB_OBJECT_LIMIT_PROCESS_MEMORY等约束 - 系统全局句柄表内存占用（
nt!PspProcessHandleTable大小随系统负载变化） - 32位进程受用户态地址空间挤压，句柄表可能提前耗尽；64位则极少遇到瓶颈
无法用单一API获取“最大句柄数”，最接近的是查询当前使用量：
HANDLE h = GetCurrentProcess();
DWORD handleCount;
if (GetProcessInformation(h, ProcessHandleCount, &handleCount, sizeof(handleCount))) {
// handleCount 是当前已分配句柄数，非上限
}
真正卡住时的错误通常是ERROR_TOO_MANY_OPEN_FILES（极少）或更常见的ERROR_NO_SYSTEM_RESOURCES，此时说明句柄表或池内存已满，而非达到某个预设阈值。
跨平台判断逻辑不能只看getrlimit返回值
即使getrlimit返回软限制为65536，也不代表你能稳开65535个socket或文件——内核还要预留一部分fd给标准流、信号处理等内部用途，而且fork()子进程会复制所有fd，可能意外突破限制。
- 生产环境应主动用
setrlimit在启动早期抬高RLIMIT_NOFILE，而不是依赖shell默认值 - 检查是否真的需要这么多句柄：异步I/O（epoll/kqueue）比阻塞式轮询更省fd；连接池复用比频繁
open/close更稳妥 - Windows上更应关注句柄泄漏——
CloseHandle漏调用比上限不足更常见，可用Process Explorer实时观察句柄增长趋势
真正难的不是读出那个数字，而是理解它在不同层级（shell、init、cgroup、内核）之间如何被继承、覆盖和截断。
