NtQuerySystemInformation是Windows下获取全系统句柄总数的唯一稳定方案，需用SystemHandleInformation（16）或SystemHandleInformationEx（64）类，提权后调用并动态分配缓冲区，再按ProcessId聚合计数定位泄漏进程。
Windows下用NtQuerySystemInformation获取句柄总数
Windows没有公开的API直接返回“全系统当前打开句柄总数”，NtQuerySystemInformation 是唯一稳定可行的方案。它属于NT内核API，需手动加载ntdll.dll并获取函数指针，不能直接链接。
关键点：必须使用SystemHandleInformation（值为16）或更安全的SystemHandleInformationEx（值为64，Win10 1607+），后者返回结构体含句柄总数字段，避免遍历整个句柄表。
- 调用前需以
SeDebugPrivilege提权，否则多数进程句柄不可见，总数严重偏低 -
SystemHandleInformationEx返回的SYSTEM_HANDLE_INFORMATION_EX结构首字段就是NumberOfHandles，无需循环计数 - 缓冲区大小需先用0长度试探，再分配——常见错误是硬编码固定大小导致
STATUS_INFO_LENGTH_MISMATCH - 32位程序在64位系统上会漏掉64位进程的句柄，务必匹配平台编译（x64优先）
句柄数暴涨时如何快速定位异常进程
拿到总数只是第一步，真正要排查泄漏得关联到具体进程。NtQuerySystemInformation返回的每个句柄条目含ProcessId和HandleValue，但不带进程名——必须自己查CreateToolhelp32Snapshot + Process32First/Next做映射。
实操建议：
- 按
ProcessId聚合计数时，用std::map比遍历快，别边扫边查进程名 - 过滤掉
System（PID 4）、smss.exe等系统进程，聚焦用户态进程（PID > 100） - 若发现某进程句柄数>10000且持续增长，大概率是GDI对象未释放或文件句柄泄漏，不是单纯“开了太多窗口”
- 注意：同一个句柄值在不同进程里是独立的，
HandleValue字段仅对所属ProcessId有效，不可跨进程比较
为什么GetProcessHandleCount返回值总是0或极小
GetProcessHandleCount看似最简单，但它只对**当前进程**有效，且要求目标进程有PROCESS_QUERY_LIMITED_INFORMATION权限。对其他进程调用基本失败，返回0是常态。
- 即使OpenProcess成功，多数情况下仍因权限不足导致
GetProcessHandleCount返回0（错误码ERROR_ACCESS_DENIED） - 该函数在Windows 8.1+对非自身进程已基本失效，文档也明确标注“may not be available for all processes”
- 不要试图用它替代
NtQuerySystemInformation——它解决的是完全不同的问题场景
跨平台兼容性：Linux/macOS怎么办
C++跨平台监控句柄数时，Windows方案完全不适用。/proc/[pid]/fd/目录是Linux事实标准，macOS则依赖proc_pidinfo + PROC_PIDLISTFDS。
关键差异：
- Linux：
scandir("/proc/self/fd", ...)可得当前进程句柄数；全系统总数需遍历/proc/[0-9]*/fd/，但需root权限且性能差 - macOS：
proc_pidinfo(pid, PROC_PIDLISTFDS, ...)返回fd数组，长度即句柄数；全系统需枚举所有PID，用proc_listpids - 没有POSIX标准API，各系统必须条件编译，别幻想一套代码通吃
- macOS上
ulimit -n限制的是每个进程的fd上限，但系统总fd数由kern.maxfiles决定，二者别混淆
真正难的不是调API，而是权限、稳定性与采样时机——比如句柄数在你调用的10ms内可能已增减数百个。监控类逻辑必须容忍抖动，别把瞬时峰值当泄漏。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
