/proc/[pid]/task/[tid]/children仅显示该线程直接fork的子进程（不含exec后的子进程树及僵尸进程），不可靠；可靠方法是遍历/proc下所有PID目录，读取/proc/[pid]/stat第4字段（ppid）匹配。
Linux下用 /proc/[pid]/task/[tid]/children 读不到子进程？
这个路径在较新内核（≥4.1）才默认启用，且需内核编译时开启 CONFIG_PROC_CHILDREN（多数发行版已开），但更关键的是：/proc/[pid]/task/[tid]/children 只显示该线程直接 fork 出的子进程（不含 exec 后的子进程树），且不包含已退出但未 wait 的僵尸子进程。实际中几乎没人靠它获取完整子进程列表。
为什么不能用 getppid() 反查子进程？
getppid() 是进程调用的，只能返回当前进程的父 PID，没法遍历系统所有进程。想反查就得扫全量 /proc 目录，逐个读 /proc/[pid]/stat 的第 4 字段（ppid），这是唯一可靠、通用的方法：
- 遍历
/proc下所有纯数字目录名（即 PID） - 打开
/proc/[pid]/stat，用空格或制表符分割，取第 4 个字段（注意：索引从 1 开始，不是 0） - 若该值等于当前进程 PID，则
[pid]是子进程 - 需加
errno == EACCES判断跳过权限不足的条目（如其他用户进程）
读 /proc/[pid]/stat 时字段顺序和格式容易错在哪？
/proc/[pid]/stat 第一行是单行文本，字段间用空格分隔，但第 2 字段（comm）是括号包裹的进程名，可能含空格（如 (chrome: GPU)），所以不能简单用 strtok 按空格切——会把进程名切碎。正确做法是：
- 先找第一个
'('和对应')'，提取出 comm 字段（含括号） - 再从
')'后第一个非空格字符开始，按空格切剩余部分 - 这样能确保第 4 个字段（ppid）位置准确
示例片段（简化）：1234 (bash) R 123 123 123 34816 ... → ppid 是 123（第 4 个字段）
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
Windows 上没有 /proc 怎么办？
Windows 没有等价的轻量级接口。必须用 Windows API：
- 调用
CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)获取进程快照 - 用
Process32First/Next遍历，检查每个PROCESSENTRY32.th32ParentProcessID是否等于当前 PID - 注意：该 API 不返回已退出但未回收的子进程（类似 Linux 的僵尸进程），也看不到以不同用户权限启动、且当前进程无权限枚举的子进程
跨平台代码里别硬写 #ifdef _WIN32 套两套逻辑——子进程列表本身语义就依赖 OS 调度模型，强行抽象只会掩盖差异。
真正难的不是读哪个文件或调哪个 API，而是理解“子进程”在不同上下文里根本不是同一个概念：fork 之后 exec 之前算不算？守护进程 double-fork 后的孙子进程要不要算？容器环境下 PID namespace 隔离后看到的 PID 还是不是真实子进程？这些没理清，代码写得再“正确”也没法满足业务需求。
