Linux下用/proc/self/fd统计文件描述符数量最可靠，直接遍历该目录并排除.、..及失效符号链接；Windows需用NtQuerySystemInformation过滤FileType为File的句柄，因HANDLE是通用对象且权限要求高。
Linux下用/proc/self/fd统计文件描述符数量
Linux进程的文件描述符（fd）本质就是内核为每个打开的文件、socket、管道等分配的整数编号，所有活动句柄都映射在/proc/self/fd/目录下。直接统计该目录项数是最可靠、开销最小的方式。
- 执行
ls -1 /proc/self/fd/ | wc -l可在shell中快速验证，C++里用opendir()+readdir()遍历更稳妥 - 注意排除
.和..，也别漏掉符号链接失效的情况（readlink()失败不计入） -
/proc/self/fd/是软链接，指向/proc/PID/fd/，无需自己拼接PID - 该方法返回的是当前时刻已分配且未关闭的fd总数，包含标准输入输出、日志文件、网络连接等全部类型
Windows下用NtQuerySystemInformation枚举句柄
Windows没有统一的“文件句柄”概念——HANDLE是通用对象句柄，可能指向文件、事件、互斥体、注册表键等。要统计“文件相关”句柄，必须结合对象类型过滤，不能只看数量。
- 调用
NtQuerySystemInformation（需ntdll.dll）获取全系统句柄表，再筛选出当前进程的条目 - 每个句柄条目含
ObjectTypeNumber，文件类型通常是27（File）或30（ALPC Port不算），但不同Windows版本可能有差异 - 必须用
GetProcessHandleCount作粗略参考：它返回进程句柄总数（含非文件类），若远大于你预期的文件数，说明存在大量event/mutex等 - 权限要求高：需要
SE_DEBUG_NAME特权，普通用户进程默认无权查询自身句柄详情
跨平台封装时别混淆“文件句柄”和“文件描述符”
很多开发者误以为getrlimit(RLIMIT_NOFILE, &rlim)返回的就是当前使用数——其实它只给出上限（rlim_cur），和实际用量无关。更危险的是把Windows的GetProcessHandleCount()当作Linux的ls /proc/self/fd | wc -l等价物。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
getrlimit()返回的是软限制，不是使用量；GetProcessHandleCount()包含所有句柄，无法区分文件/非文件 - POSIX标准里没有“获取当前fd数”的系统调用，Linux靠
/proc伪文件系统实现，属于实现细节，不可移植 - 若你在写跨平台库，建议明确接口语义：比如命名为
get_open_file_descriptor_count()，并在Windows版文档里注明“仅统计FileType为File的对象” - 调试时优先用平台原生工具验证：Linux用
lsof -p $PID | wc -l，Windows用handle.exe -p $PID（Sysinternals套件）
注意/proc/self/fd的竞态与权限边界
虽然/proc/self/fd/读取很快，但在多线程频繁open/close的场景下，两次统计结果可能不同——这不是bug，而是真实状态快照。更隐蔽的问题是权限：容器化环境（如Docker）或chroot沙箱中，/proc可能被挂载为只读或受限视图。
立即学习“C++免费学习笔记（深入）”；
- 如果
opendir("/proc/self/fd")返回NULL且errno == EACCES，说明进程无权访问procfs，此时只能回退到getrlimit()估算上限 - 某些安全加固策略（如SELinux策略、gVisor）会拦截对
/proc/self/fd/的读取，返回空目录而非错误，导致统计结果为0 - 不要缓存该值超过100ms——尤其在连接池、日志轮转等高频IO场景，过期数据会误导判断
/proc/self/fd，Windows必须接受“文件句柄”定义模糊的事实，而任何试图抽象成单一跨平台API的尝试，都会在边界 case 上暴露语义鸿沟。 
