pstree -p 是最准最快的方式，直接输出带PID的缩进树，括号内数字即真实PID，可直用于kill或strace；而ps -ef或ps --forest为扁平列表，父子关系需手动比对PPID，易跳层、漏看、断链。
pstree -p 是最准、最快的方式，直接输出带 PID 的缩进树，括号里的数字就是真实 PID，可直接用于 kill 或 strace。
为什么不用 ps -ef 或 ps --forest
ps 输出是扁平列表，父子关系藏在 PPID 字段里，得手动比对——比如看到 curl 的 PPID 是 1245，还得再查一遍 PID 1245 是不是 bash，容易跳层、漏看、搞错层级。而 pstree -p 用缩进+连接符天然表达派生链：sshd(790)───bash(1245)───curl(1267)，一眼就知道 curl 是 bash 启动的，bash 又挂在 sshd 下。
常见错误现象：用 ps -eo pid,ppid,comm | grep curl 查到 PPID，但没验证该 PPID 是否还存活，或是否已被回收（如刚 fork 就 exit 的进程），导致链路断在中间。
- 缩进越深，层级越低；父进程一定在上一级缩进位置
-
ps -eo pid,ppid,comm,state是交叉验证的底线手段，一旦pstree看不到某进程，就立刻切过去看原始字段 -
ps --forest虽能模拟树形，但不显示 PID，也不合并同名进程，信息冗余且难定位
pstree -p 为什么默认只显示当前用户进程
因为 pstree 默认行为是按会话过滤，只展示当前终端登录用户启动的进程树。root 启动的服务（如 nginx、dockerd）及其 worker 进程不会出现，哪怕它们实际派生了你的子进程。
使用场景：排查你起的脚本为何卡住，或确认某个 python 进程是不是从你的 bash 派生而来——这时默认行为刚好够用；但查服务异常、僵尸进程、systemd 管理的 daemon 时，就一定得加 sudo。
- 查全系统树：
sudo pstree -p - 查特定用户：
pstree -p root或pstree -u www-data - 别信
pstree -P：这个选项根本不存在，所有文档里写它的一律是错的
怎么快速聚焦某个服务或 PID 的父子链
不要从全系统树里肉眼扫——尤其当 sudo pstree -p 输出几百行时。直接指定目标缩小范围：
- 查
nginx所有进程及子树：pstree -p nginx（注意大小写，匹配的是comm字段，不是路径） - 查 PID 为 1234 的进程及其所有后代：
pstree -p 1234 - 反向追溯已知子进程来源：
pstree -s 1234，输出形如systemd(1)───sshd(790)───bash(1234) - 若服务由 systemd 启动，加
--show-parents回溯 unit：pstree -ap --show-parents 1234
容易踩的坑：同名进程被自动合并为 5*[nginx]，不代表 5 个独立进程，可能是多线程或重复 fork；带花括号的条目如 {gdbus} 是线程，不是子进程，除非加 -t 显式开启线程显示。
真正容易被忽略的边界情况
pstree 默认不显示跨用户、跨 PID namespace、已僵死、或刚 fork 还没 exec 的进程。比如容器内进程、Docker/K8s 场景下的 init 进程、或 shell 脚本里 sleep & 后立刻退出的父 shell，都可能让树“断掉”。
这时不能只盯着 pstree 输出，必须立刻补查：ps -eo pid,ppid,comm,state | grep -E "^(1234|<your-ppid>)"</your-ppid>，确认 PPID 是否真实存在、状态是否为 Z（zombie）或 S（sleeping），再决定下一步是 kill -9 还是 strace -p。
