最可靠方法是遍历 /proc/self/fd 目录计数；Linux 下用 opendir/readdir 统计符号链接项，macOS/FreeBSD 用 sysctl(KERN_PROC_FDNUM) 获取活跃 fd 总数，避免使用 getrlimit、FD_SETSIZE 或暴力探测。
Linux 下通过 /proc/self/fd 目录统计 fd 数量最可靠
在 Linux 系统上，/proc/self/fd 是当前进程所有打开文件描述符的符号链接目录，直接遍历它比调用系统 API 更准确、更轻量，且能反映内核实际维护的 fd 状态（包括 socket、eventfd、timerfd 等所有类型）。
常见错误是误用 getrlimit(RLIMIT_NOFILE, &rlim) ——它只返回最大允许值（soft limit），不是当前已用数量；也有人尝试 fcntl(fd, F_GETFD) 从 0 往上暴力探测，但会漏掉已被 close() 但尚未被内核回收的 fd（如子进程继承后关闭父进程 fd 的竞态场景），还可能触发无效系统调用开销。
- 用
opendir("/proc/self/fd")打开目录，再用readdir()遍历，跳过.和.. - 每个目录项名是数字字符串（如
"12"），可直接计数，无需stat()或readlink() - 注意：该方式依赖 procfs 挂载，容器环境需确保
/proc可见（多数默认满足） - 示例片段：
DIR* dir = opendir("/proc/self/fd"); int count = 0; if (dir) { struct dirent* ent; while ((ent = readdir(dir)) != nullptr) { if (ent->d_type == DT_LNK && strcmp(ent->d_name, ".") && strcmp(ent->d_name, "..")) { count++; } } closedir(dir); }
macOS 和 FreeBSD 需用 sysctl + KERN_PROC_FDNUM
macOS 不提供 /proc，必须走 sysctl 接口。使用 KERN_PROC_FDNUM 可直接获取当前进程打开 fd 总数，无需遍历或解析文本。
容易忽略的是：该接口返回的是 int 类型值，但 sysctl 调用需传入指针和长度，且必须指定目标进程 pid（getpid() 即可）。若传错缓冲区大小或忽略错误码，会静默失败。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 声明
int mib[3] = {CTL_KERN, KERN_PROC, KERN_PROC_FDNUM} - 调用前先用
sysctl(mib, 3, nullptr, &len, nullptr, 0)获取所需缓冲区大小 - 再分配
int* val并调用sysctl(mib, 3, val, &len, nullptr, 0)，成功时*val即为总数 - FreeBSD 同样支持此
mib，但部分旧版本需用KERN_PROC_FILEDESC配合解析结构体，不推荐
跨平台封装要注意 errno 和边界行为
不同系统对“无效 fd”或“已关闭但未回收 fd”的处理不一致：Linux /proc/self/fd 中不会出现已关闭 fd 的条目；而 macOS sysctl 返回的是内核当前维护的活跃 fd 计数，语义一致。但封装时若统一用 errno == ENOENT 判断路径不存在，会在 macOS 上误判——那里压根不走文件路径。
- 优先检测
/proc/self/fd是否可访问（access("/proc/self/fd", F_OK) == 0），存在则走 Linux 分支 - 否则检查
CTL_KERN是否可用（sysctlbyname("kern.version", ...)测试），再走 BSD 分支 - 不要依赖
__linux__或__APPLE__宏做硬编译分支——容器中可能运行 Linux 内核但用户态是 musl，宏定义失效 - 返回值应为
ssize_t，避免int在高 fd 场景下溢出（虽然极少见，但监控场景可能达数万）
不要用 getdtablesize() 或 FD_SETSIZE
getdtablesize() 返回的是进程文件描述符表的**分配上限**（通常是 RLIMIT_NOFILE soft limit），不是当前使用量；FD_SETSIZE 是 fd_set 位图的静态大小（常为 1024），与实际 fd 数量完全无关，且在现代系统中早已被 epoll/kqueue 绕过。
曾有代码用 FD_SETSIZE 做 for 循环探测每个 fd 是否有效，不仅逻辑错误，还会在 fd 稀疏分布时严重拖慢性能（比如只开了 fd 3 和 fd 99999，却要扫完 1024 次）。
- 永远不要把
FD_SETSIZE当作当前 fd 总数 -
getdtablesize()的返回值需配合fcntl(fd, F_GETFD)才能判断单个 fd 是否有效，无法直接得总数 - 这种探测方式在多线程环境下也不安全：遍历时另一个线程可能正在
close()或dup()
C++ 没有标准库函数获取 fd 总数，最终实现必然依赖平台 API；最易出错的地方不是逻辑，而是混淆“上限”“容量”和“实际使用量”这三个概念——尤其当监控指标突增却查不到对应 fd 时，大概率是用了 getrlimit 或 FD_SETSIZE。
