Linux下用/proc目录统计进程数最可靠，因其轻量、无需权限、不依赖外部命令；遍历/proc下纯数字目录并读取stat文件过滤内核线程和僵尸进程即可。
Linux 下用 /proc 目录统计进程数最可靠
Linux 没有统一的“后台进程”定义，但通常指非会话首进程、无控制终端、且状态为 R（运行）或 S（睡眠）的进程。直接读取 /proc 是最轻量、无需权限、不依赖外部命令的方式。
-
/proc下每个数字子目录对应一个进程 PID，只要能读取该目录，就说明进程存在 - 过滤掉内核线程（
/proc/<pid>/stat第 3 字段为K）和僵尸进程（状态为Z）更贴近“正在运行”的语义 - 不需要调用
fork+exec启动ps或system()，避免 shell 解析风险和性能开销 - 示例逻辑：遍历
/proc下所有纯数字目录 → 读/proc/<pid>/stat→ 提取第 3 字段（状态）和第 8 字段（tty 链接是否为空）→ 统计满足条件的个数
Windows 上必须用 CreateToolhelp32Snapshot 遍历进程
Windows 没有类似 /proc 的伪文件系统暴露进程细节，GetProcessList 等旧 API 已废弃，唯一稳定方式是使用 Toolhelp API 获取快照后逐个检查。
-
CreateToolhelp32Snapshot必须传TH32CS_SNAPPROCESS，否则返回空；调用后需立即用Process32First和Process32Next迭代 - “后台进程”在 Windows 中没有标准定义，常见做法是排除会话 0 中的系统服务（
th32SessionID == 0）和前台窗口拥有者（可用GetForegroundWindow+GetWindowThreadProcessId辅助判断） - 注意
PROCESSENTRY32结构体需初始化dwSize字段，否则Process32First失败返回FALSE且GetLastError()可能为ERROR_NO_MORE_FILES（误导性错误码） - 不要用
EnumProcesses配合OpenProcess—— 它无法获取会话 ID，且对保护进程（如 CSRSS）会失败，导致漏计
跨平台代码里别硬编码“后台”逻辑，先明确业务需求
所谓“后台进程总数”在不同场景下含义差异极大：监控工具可能要排除所有服务，调试器可能只关心当前用户会话下的非 GUI 进程，容器环境甚至要过滤掉 init 进程及其子树。
- 如果目标是“当前登录用户的非前台进程”，Linux 应检查
/proc/<pid>/status中的Uid和TTY字段；Windows 应结合WTSQuerySessionInformation获取当前活动会话再比对th32SessionID - 如果只是粗略统计“活着的用户态进程”，Linux 只需统计
/proc/[0-9]*目录数（跳过/proc/sys等非 PID 目录），Windows 用Process32Next循环计数即可 - 避免在循环中频繁调用
getppid()或GetParentProcessId判断是否为“后台”——开销大且语义模糊；优先用已有的状态/会话/TTY 信息
别忽略权限与竞态问题
进程列表是动态变化的，任何统计都只是瞬时快照；同时，权限不足会导致部分进程不可见，直接造成计数偏低。
立即学习“C++免费学习笔记（深入）”；
- Linux 下普通用户无法读取其他用户的
/proc/<pid>/stat（Permission denied），但可以列出目录名；若需完整统计，必须以 root 运行或用cap_sys_ptrace能力 - Windows 上非管理员进程无法打开某些系统进程句柄（如 PID 4 的 System 进程），但
Process32Next仍能枚举其条目——只是th32ProcessID可读，其他字段（如内存使用）可能为 0 - 两次遍历之间进程可能已退出或启动，严格意义的“总数”不存在；如需较准数值，建议单次快照 + 尽量减少处理时间，而非尝试加锁或重试
/proc 遍历时遇到符号链接或临时子目录（如 /proc/self、/proc/thread-self）要跳过，Windows 下忘记在 Process32First 前设 pe32.dwSize = sizeof(PROCESSENTRY32) 会导致整个循环静默失败。 
