Linux下用getrlimit获取RLIMIT_NOFILE可得进程软硬限制，软限制（rlim_cur）为当前生效值，硬限制（rlim_max）为其上限；macOS行为一致但默认值更保守；Windows无等价机制。
Linux 下用 getrlimit 获取进程文件描述符软硬限制
在 Linux 系统中，单个进程能打开的最大文件句柄数由 RLIMIT_NOFILE 限制控制，分软限制（soft limit）和硬限制（hard limit）。软限制可被进程自行调低或在权限允许时调高；硬限制只能由 root 提升，普通进程只能降低它。
直接调用 getrlimit 即可读取当前值：
#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是当前生效的软限制，即open()等系统调用实际受阻的阈值 -
rl.rlim_max是该进程能设到的最高软限制（除非是 root，否则不能突破此值） - 若程序由 systemd 启动，需检查
LimitNOFILE=配置项，它会覆盖 shell 的 ulimit 设置 - 注意：该值反映的是「当前进程」的限制，不是系统全局最大值（如
/proc/sys/fs/file-max）
macOS 上 getrlimit 行为一致但默认值不同
macOS 同样支持 getrlimit(RLIMIT_NOFILE, ...)，语义与 Linux 完全相同。但默认软限制通常更低（例如 256），硬限制可能高达 10240 或更高，具体取决于系统版本和启动方式。
- 终端中启动的进程继承自 shell 的 ulimit，可通过
ulimit -n查看 - GUI 应用（如从 Finder 双击运行）可能继承自 launchd，其默认限制更保守，需在
plist中显式配置SoftResourceLimits/HardResourceLimits - 调用
setrlimit尝试提限时，若超出硬限制会返回EPERM，不是EAGAIN或EMFILE
Windows 没有等价的 per-process 文件句柄硬限额
Windows 不提供类似 RLIMIT_NOFILE 的内核级 per-process 句柄总数限制。它的句柄数量受限于进程可用内存、系统 Paged Pool 大小，以及每个句柄对象的内核开销。
立即学习“C++免费学习笔记（深入）”；
- 可通过
GetProcessHandleCount()获取当前已打开句柄数，但它不告诉你“上限”，只返回实时计数 - 没有标准 API 能查到“还能再开多少个”，因为这个“上限”是动态浮动的
- 实践中，当
CreateFile、socket等返回INVALID_HANDLE_VALUE且GetLastError() == ERROR_TOO_MANY_OPEN_FILES时，才说明触达了某种资源瓶颈——但这更多是历史兼容层（如 C runtime 的_open）模拟的限制，非内核强制 - 若依赖跨平台统一逻辑，建议在 Windows 上把软性上限设为一个保守值（如 8192），并配合
GetProcessHandleCount()做运行时预警
为什么不能只看 /proc/<pid>/limits？
虽然 Linux 下 /proc/<pid>/limits 可人工查看，但它本质是 getrlimit 的文本封装，且存在几个关键盲区：
- 该文件只对本用户拥有读权限的进程可见；调试别人进程时往往打不开
- 它显示的是进程启动时的限制，若进程中途调用
setrlimit修改过，/proc/<pid>/limits不会刷新（内核不会回写） - 容器环境（如 Docker）中，cgroup v1 的
tasks和cgroup.procs可能导致/proc/<pid>/limits显示宿主机值，而实际生效的是 cgroup 的pids.max或io.max等间接约束 - 真正可靠的永远是进程内调用
getrlimit——它读的是内核为该 task_struct 维护的实时字段
LimitNOFILE= 必须在 service unit 文件中显式设置，且 reload 后需 restart 服务才能生效；仅 systemctl daemon-reload 不够。 
