Linux下应调用getrlimit(RLIMIT_NOFILE)获取进程文件描述符软硬限制，/proc/sys/fs/file-max是系统级总量，sysconf(_SC_OPEN_MAX)返回编译时上限；macOS行为类似但默认软限常为256；Windows无等价API，需监控句柄数与非分页内存。
Linux下用getrlimit获取进程文件描述符上限
Linux系统中，单个进程能打开的最大文件句柄数由RLIMIT_NOFILE资源限制控制，不是全局配置值，而是每个进程独立继承的软限/硬限。直接读/proc/sys/fs/file-max得到的是全系统总限额，和单个进程无关。
正确做法是调用getrlimit并传入RLIMIT_NOFILE：
#include <sys/resource.h>
#include <iostream>
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
std::cout << "soft limit: " << rl.rlim_cur << "
";
std::cout << "hard limit: " << rl.rlim_max << "
";
}
-
rl.rlim_cur是当前生效值（软限），可被进程自己调低，或在未超硬限时调高 -
rl.rlim_max是软限能设到的最高值（硬限），普通进程无法提升，需root权限才能上调 - 该值继承自父进程（如shell），启动时可能已被systemd、supervisord或ulimit命令修改过
macOS上行为一致但需注意硬限默认值
macOS也支持getrlimit(RLIMIT_NOFILE, ...)，语义与Linux相同，但默认硬限通常为unlimited（即RLIM_INFINITY），而软限常为256或2560——这容易让人误以为上限很低，其实只是软限保守。
检查是否真受限，关键看rl.rlim_cur：如果它等于rl.rlim_max且远小于预期，才说明被显式限制了。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- macOS 10.15+ 默认软限可能被
launchd设为256，需在plist中配LimitNumberOfFiles调整 - 终端里执行
ulimit -n显示的也是当前shell的rl.rlim_cur - 不要依赖
sysconf(_SC_OPEN_MAX)——它返回编译时上限，不反映运行时实际限制
Windows没有等价的“文件句柄数限额”概念
Windows不按“文件句柄数”统一设限，而是受三类资源分别约束：per-process handle count、non-paged pool memory、以及具体对象（如文件）的内核资源池。不存在一个getrlimit式的API能直接读出“最大可打开文件数”。
最接近的指标是当前进程句柄总数上限，可用GetProcessHandleCount查实时使用量，但无法得知理论最大值：
HANDLE h = GetCurrentProcess();
DWORD count;
if (GetProcessHandleCount(h, &count)) {
// count 是当前已分配句柄数，不是上限
}
- 32位进程默认句柄表大小约16K，64位通常更高，但会随非分页内存耗尽而提前失败
- 错误码
ERROR_TOO_MANY_OPEN_FILES极少出现；更常见的是ERROR_NO_SYSTEM_RESOURCES或ERROR_COMMITMENT_LIMIT - 若需估算容量，应监控
\Process(*)\Handle Count性能计数器，并结合GlobalMemoryStatusEx观察ullAvailNonPagedPoolBytes
跨平台代码别硬编码magic number
不同系统对“无限制”的表示不同：RLIM_INFINITY（Unix）、INFINITE（Windows API）、或0x7FFFFFFF（某些旧libc）。试图用固定数值判断“是否受限”必然出错。
- Unix系：比较
rl.rlim_cur与rl.rlim_max是否相等且极大，不如直接用rl.rlim_cur作为安全上限 - Windows：不要尝试“算出最大值”，应在
CreateFile失败后根据GetLastError()区分是路径问题、权限问题，还是资源枯竭 - 所有平台都建议：打开文件前先检查
rlimit或等效指标，失败时记录errno或GetLastError()，而不是假设某个固定数字就是瓶颈
真正麻烦的从来不是读这个数，而是当rl.rlim_cur只有1024却要开几千个socket时，你得决定是改ulimit、重用连接，还是换异步IO模型——数值本身只是起点。
