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|。先把 PPID 是不是真的还在、进程状态到底是不是 Z（zombie）或 S（sleeping）查清楚，再判断后面该走哪条路：是直接 kill -9，还是先用 strace -p 继续盯一下。
