应优先使用 pkill 而非 killall，因 killall 仅匹配进程短名（如 python3），易误杀；pkill -f 可匹配完整命令行，支持正则、路径和参数，可控性更高。
直接用 pkill，别用 killall —— 后者只看进程短名（如 python3），不看路径和参数，极易误杀；而 pkill 支持正则、可匹配完整命令行，可控性高得多。
为什么 killall python3 很危险
killall 读取的是 /proc/[pid]/comm，这个文件只存二进制名（比如 python3），不存启动路径或参数。所以：
- 运行
python3 /opt/app/main.py和python3 ~/test.py，都会被killall python3一起干掉 -
killall nginx*报错No such process—— 它根本不支持通配符或正则 - IDE 里调试的
python3、终端里随手起的python3 -c "print(1)"全部躺枪
pkill -f 匹配完整命令行才靠谱
-f 让 pkill 去匹配 /proc/[pid]/cmdline，也就是你敲进 shell 的整条命令（含空格、路径、参数）。实操前务必加 -l 预览：
- 查所有监听 8001 的 gunicorn：
pkill -lf "gunicorn.*8001" - 只杀用户
www-data启动的：pkill -u www-data -f "php-fpm" - 避免匹配到自身 grep：
pgrep -f "node server.js" | xargs kill比直接pkill -f "node server.js"更稳 - 注意 shell 转义：写成
pkill -f 'node.*3000'比双引号更安全，防止.被 shell 展开
别一上来就 -9，先发 SIGTERM
kill -9（即 SIGKILL）不给进程任何清理机会，数据库连接不断开、临时文件不清理、锁不释放——轻则日志断点，重则数据损坏。
- 默认就是
SIGTERM（-15）：pkill -f "myapp"等价于pkill -15 -f "myapp" - 优雅退出后等 2 秒再检查：
pkill -f "myapp" && sleep 2 && pgrep -f "myapp" - 确认还活着再补刀：
pkill -9 -f "myapp" - 用
kill -0 PID只检测是否存在，不发信号，适合写在脚本里做判断
真正难的不是怎么发信号，而是想清楚“哪些进程属于同一逻辑单元”——比如同个服务的不同 worker、同一部署目录下的多个 node 实例。这时候光靠名字没用，得靠 -f + 路径/端口/用户等上下文限定，否则删着删着就把监控 agent 或日志采集器顺手 kill 掉了。
