ps aux 并非真正“全进程”，不显示内核线程和跨 namespace 容器进程；其核心价值是展示用户态进程、完整资源字段及跨用户可见性。
ps aux 是最常用但容易误解的“全进程”命令
它确实能列出几乎所有进程，但不是字面意义的“全部”——ps aux 不显示内核线程（如 kthreadd、rcu_gp），也不显示某些 namespace 隔离下的容器进程（除非你在对应命名空间里执行）。它的核心价值在于：用户态进程 + 完整资源字段 + 跨用户可见。
常见错误是以为 ps aux | grep nginx 一定能抓到所有 nginx 进程。其实如果 nginx 启用了 master-worker 模式且 worker 进程被 cgroup 限制或运行在不同用户下，可能漏掉部分；更稳妥的是加 -f 显示完整命令行：ps -ef | grep nginx，或直接用 pidof nginx 获取 PID 列表。
-
ps aux中的U表示用户，%CPU和%MEM是瞬时占用率，不是平均值 - 想看进程树关系？别硬读
ps aux输出，改用pstree -p或ps -e --forest - 注意
ps是快照命令：执行完就结束，无法反映持续行为——这点常被误当成 top 的替代品
top 实时监控时 CPU 占用率不准的三个原因
你看到某进程长期显示 95% CPU，但它实际可能只占 10% ——这不是 bug，而是 top 默认按单核归一化显示。比如 4 核机器上一个满载单线程进程，在 top 里就是 100%，但真实占用是 25% 的总 CPU 资源。
另一个坑是 top 默认刷新间隔为 3 秒，而高频率短时爆发型进程（如 cron 触发的脚本）可能刚好在两次采样之间完成，导致完全看不到峰值。
- 按
1键可切换显示各 CPU 核心负载，避免单核过载被平均掩盖 - 用
top -n 1获取单次快照，适合脚本调用；top -b -n 1输出纯文本，方便管道处理 - 内存列里的
VIRT（虚拟内存）≠ 实际使用量，RES（常驻内存）才接近真实物理内存占用，SHR是共享库大小，别误判为“多进程共用节省了内存”
查特定进程或用户时，别依赖模糊 grep
ps aux | grep python 会把自己这条 grep 命令也列出来，干扰判断；更糟的是，如果目标进程名含空格或特殊字符（如 node server.js），grep 可能匹配不全。
真正可靠的方式是用 ps 原生命令过滤：
- 查指定用户：
ps -u www-data（比ps aux | grep www-data干净得多） - 查指定 PID：
ps -p 1234，支持多个 PID：ps -p 1234,5678 - 查进程名精确匹配：
pgrep -f "nginx: master process"或pidof nginx（只返回 PID 数字） - top 里也能限定：
top -u www-data或top -p $(pgrep -f "redis-server")
僵尸进程（Z）和孤儿进程（<defunct></defunct>）怎么识别和处理
僵尸进程状态标为 Z，出现在 ps aux 的 STAT 列；它已终止，但父进程没调用 wait() 回收，仍占 PID 和少量内核资源。大量 Z 进程会耗尽 PID 空间（默认 32768），导致新进程无法启动。
孤儿进程不是问题——它只是父进程挂了，被 init/systemd 接管（PID 变成 1 或 1960），状态仍是 S 或 R，正常运行。
- 查僵尸：
ps aux | awk '$8 ~ /Z/ {print}'，重点关注其 PPID（父进程 ID） - 不能用
kill -9杀僵尸——它已经死了，只能杀它的父进程，逼父进程退出后由 init 回收；或重启父服务 - 若父进程是 systemd，可尝试
systemctl kill --signal=SIGCHLD <service></service>触发子进程回收
真正要警惕的不是 Z 进程本身，而是它背后暴露的父进程 bug：不处理子进程退出信号、逻辑卡死、或未正确调用 waitpid()。这类问题在 C/Go 编写的守护进程中尤其常见。
