应优先用pkill -f配合-l预览再发SIGTERM；因killall只匹配短进程名且不支持正则，无法精准识别带参数的脚本，而pkill -f匹配完整命令行，支持用户限定、转义和安全验证。
别用 killall 直接杀带参数的脚本，它根本匹配不到你想要的进程；优先用 pkill -f 配合预览，再发 SIGTERM（默认不加数字），不是 -9。
为什么 killall python3 会误杀所有 Python 进程
killall 只读取 /proc/[pid]/comm，这个文件里只存短名称（比如 python3），不存路径、参数或启动方式。你运行 python3 /opt/app/main.py 和 python3 -m http.server 8000，killall python3 都会把它们干掉——包括你 IDE 里正在调试的、终端里随手起的测试进程，甚至系统级服务。
-
killall nginx*报错No such process：它不支持通配符或正则 -
killall 'nginx.*'同样无效：匹配逻辑是纯字符串精确比对，不是模式匹配 - 验证当前进程名：运行
ps -eo comm,args | head -5，对照comm列（短名）和args列（完整命令行）
pkill -f 匹配完整命令行才靠谱
你要杀的是 gunicorn --bind 0.0.0.0:8001，或者所有从 /var/www/myapp/ 启动的 node 进程？pkill -f 是唯一能靠得住的选项，它匹配的是 /proc/[pid]/cmdline，也就是你敲进 shell 的整条命令（含空格、路径、参数）。
- 务必先加
-l预览：pkill -lf "gunicorn.*8001"，确认 PID 和对应命令是否真符合预期 - 注意 shell 转义：双引号内
.是字面量，.*才表示任意字符；写成pkill -lf 'gunicorn.*8001'更稳妥 - 限定用户更安全：
pkill -u www-data -f "php-fpm"不会误伤其他用户的同名进程 - 避免自匹配：
pkill -f "python3 server.py"可能意外匹配到grep "python3 server.py"自身，加-v或先用pgrep -f查再杀
别一上来就 kill -9，SIGTERM 才是默认行为
kill、killall、pkill 默认都发 SIGTERM（信号 15），这是设计用来优雅退出的：进程可以关闭数据库连接、释放锁、保存临时状态。直接上 -9 意味着进程无法拦截、立刻终止，轻则日志断点，重则数据损坏。
- 先发 TERM：
pkill -f "myapp" && sleep 2，再检查是否还活着 - 确认无响应后再补 KILL：
pkill -9 -f "myapp" - 用
kill -0 PID检测进程是否仍在运行（不发信号，只查状态） -
killall -TERM nginx和killall nginx效果一样，后者默认就是-TERM
systemd 服务不能硬杀，xargs 要加 -r
如果进程是通过 systemctl start nginx 启的，直接 kill 它可能被 systemd 自动拉起，或者状态变 inconsistent（systemctl status 显示 inactive but running）——这种必须用 systemctl stop。
- 批量杀时，
pgrep nginx | xargs kill遇到空输入会报错，加-r规避：pgrep nginx | xargs -r kill -
xargs默认一次传全部 PID 给一个kill命令，和逐个kill效果一致但更高效 - 需要多步操作（比如先 log 再 kill）才用
-I {}：pgrep node | xargs -r -I {} sh -c 'echo "killing {}"; kill {}'
真正难的不是怎么发 kill，而是判断“这个命令行片段到底代表哪个业务实例”，以及“它有没有在做清理工作”。预览、限定用户、等几秒再强杀，这三步漏掉任何一步，都可能让问题从运维变成救火。
