Linux通过遍历/proc下纯数字命名的目录统计活跃进程数，Windows通过CreateToolhelp32Snapshot枚举PROCESS_ENTRY32；二者语义不同，Linux包含内核线程而Windows不包含，且均返回采样时刻近似值。
Linux 下用 /proc 目录遍历获取活跃进程数
Linux 没有系统级 API 直接返回“当前活跃进程总数”，但 /proc 是最可靠、开销最小的途径：每个进程对应一个以 PID 命名的子目录，只要统计 /proc 下数字命名的目录数量即可。
注意：/proc 中非数字目录（如 self、sys、net）必须跳过；部分内核线程可能无完整 stat 或 status 文件，但目录存在即代表内核已注册该 task —— 所以只看目录名是否全数字，不验证内容。
- 用
opendir("/proc")+readdir()遍历，对每个d_name调用std::all_of(..., ::isdigit)判断是否纯数字 - 避免用
system("ps aux | wc -l")：启动 shell 开销大，且ps默认过滤掉内核线程，结果偏小 - 不要依赖
/proc/sys/kernel/pid_max：它只是 PID 上限，不是当前使用量
Windows 下用 CreateToolhelp32Snapshot 枚举进程
Windows 必须走 Win32 API，CreateToolhelp32Snapshot 是唯一稳定方式；不能靠 EnumProcesses（需额外 OpenProcess 获取名字，权限失败会导致漏计数）。
关键点在于 snapshot 类型选 TH32CS_SNAPPROCESS，然后用 Process32First / Process32Next 循环遍历 —— 即使某个进程在枚举中途退出，也不会 crash，API 保证一致性。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 调用前必须
#include <tlhelp32.h>并链接lib: kernel32.lib -
PROCESSENTRY32结构体的th32ProcessID字段为 0 时，表示无效项，应跳过 - 不需要调用
CloseHandle之前做任何字符串清理 ——szExeFile是快照内的只读缓冲区，直接用即可
C++ 跨平台封装要注意的陷阱
别写 “一套代码 if-else 切平台” 的宏封装 —— 进程定义本身就不一致：Linux 的线程和进程共享 PID 命名空间，Windows 的线程 ID 完全独立于进程 ID。所谓“活跃进程数”，Linux 数的是 task_struct 实例数（含内核线程），Windows 数的是 PROCESS_INFORMATION 级别的进程对象数（不含线程）。
- Linux 计数结果通常比 Windows 高 10%–30%，主因是内核线程（如
kthreadd、rcu_gp）在/proc中有目录，但 Windows 不将其视为“进程” - 不要试图用
std::thread::hardware_concurrency()估算 —— 它返回逻辑核心数，和进程数毫无关系 - 若需长期监控，Linux 推荐
inotify监听/proc目录创建/删除事件；Windows 推荐用 WMI 的Win32_ProcessStartTrace/Win32_ProcessStopTrace，而非轮询
为什么 GetProcessCount 这种函数不存在
操作系统内核根本不维护一个全局“当前进程总数”变量 —— 进程是分散管理的：Linux 用红黑树挂载到 init_task 的子节点，Windows 用 EPROCESS 链表挂载在系统进程对象上。每次查询都得现场遍历，没有缓存，也没有原子计数器。
这意味着任何“获取总数”的操作本质都是竞态敏感的：你数到 1234 的瞬间，可能已有两个进程退出、三个新进程启动。所以所有方案返回的都是采样时刻的近似值，不是精确快照。
真正容易被忽略的是权限问题：Windows 上低完整性进程（如浏览器沙箱）调用 CreateToolhelp32Snapshot 可能成功，但部分进程的 szExeFile 为空或访问拒绝 —— 此时仍应计入总数（PID 存在即算活跃），而不是跳过。
