pgrep 比 ps aux | grep 更可靠，因其直接读取 procfs、不产生干扰进程、默认输出纯净 PID、支持 -f 匹配完整命令行、精确匹配（-x）、多条件组合（-u/-c/-o/-d）及权限与空格处理。
直接用 pgrep 就能干净拿到 PID，不用再写 ps aux | grep 加过滤，也避开了 grep 自身进程混入结果的坑。
为什么 pgrep nginx 比 ps aux | grep nginx 更可靠
后者会把 grep nginx 这行也当匹配项输出，得额外加 grep -v grep 才能剔除；pgrep 从 procfs 直接读取进程信息，不启动新进程，天然无干扰。
- 默认只输出纯数字 PID，每行一个，可直接管道给
kill、ps等命令 - 内核限制进程名最多显示前 15 字符，
ps aux显示不全，但pgrep的-f选项能绕过这个限制 - 没有“意外匹配”：比如查
bash，pgrep bash不会匹配到bashful或rbash（除非加-i或正则）
pgrep -f 匹配完整命令行才是日常刚需
很多服务启动时进程名还是 python 或 java，真正区分靠参数。这时只查进程名根本找不到目标。
-
pgrep -f "python manage.py runserver"→ 找到 Django 开发服务器 -
pgrep -f "java.*-jar.*app.jar"→ 匹配带 jar 参数的 Java 进程 -
pgrep -f "nginx: worker process"→ 区分 master 和 worker（注意空格和冒号要写全） - 不用
-f时，pgrep python可能返回几十个无关的 Python 进程
按用户、精确名、数量统计这些操作别硬记参数
实际运维中高频组合就那么几个，记住场景比死背选项更有效：
- 查某个用户的全部相关进程：
pgrep -u www-data nginx - 确认是不是只有一个实例在跑：
pgrep -c nginx返回1才安心 - 只想杀掉最老的那个（比如重启后残留的老进程）：
pgrep -o nginx | xargs kill - 确保完全匹配进程名，避免误伤：
pgrep -x sshd不会匹配到sshd_config或ssh-agent - 多个关键词一起查：
pgrep -f "redis|mysql"（注意 shell 会解释管道符，得加引号）
容易被忽略的细节：分隔符、空格、权限
pgrep 输出默认是换行分隔，但脚本里拼接命令时可能需要逗号或空格——这时候 -d 就不能省：
-
pgrep -d, -f "node server.js"→ 输出1234,5678，方便塞进kill命令 - 命令行里有空格或特殊字符（如
./my script.sh），必须用双引号包裹整个模式，单引号不行（shell 不展开变量） - 普通用户只能查自己进程，
pgrep -u root必须用 root 权限执行，否则静默返回空 -
pgrep -P $PID查子进程时，父进程若已退出，结果为空——不是命令错，是进程树已变
