结论是：别一上来就 kill -9，先用 kill（默认 sigterm）试试；真不行再升级信号；killall 和 pkill 是按名字操作的快捷方式，但容易误杀。用 kill 按 pid 杀进程需先查 pid（如 pgrep nginx），再执行 kill 12345（优雅退出）或 kill -9 12345（强制终止）；killall 匹配可执行文件名，pkill 默认匹配完整命令行，二者均需谨慎防误杀。
kill -9，先用 kill（默认 SIGTERM）试试；真不行再升级信号；killall 和 pkill 是按名字操作的快捷方式，但容易误杀**。
怎么用 kill 按 PID 杀进程？
这是最基础也最安全的方式——你得先知道目标进程的 PID。
- 查 PID：
ps -ef | grep "nginx"或更精准的pgrep nginx（只输出数字 PID） - 发终止信号：
kill 12345（发送 SIGTERM，即信号 15，允许进程自行清理） - 强制终止：
kill -9 12345（发送 SIGKILL，内核立刻回收资源，进程无法拦截） - 别乱用
-9：比如数据库、Redis、正在写文件的进程，kill -9可能导致数据损坏或状态不一致
killall 和 pkill 有什么区别？
两者都按名字操作，但匹配逻辑和默认行为不同，容易踩坑。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
killall nginx：匹配 **完全一致的可执行文件名**（如/usr/sbin/nginx），不匹配带参数的命令行 -
pkill nginx：默认匹配 **整个命令行字符串**（包括参数），所以nginx -c /etc/nginx.conf也能被干掉 - 加
-f才让killall匹配全命令行：killall -f "python3 server.py" -
pkill支持正则：pkill -f "node.*api.js"；killall不支持 - 权限限制相同：普通用户只能杀自己启动的进程，root 才能跨用户操作
为什么 kill 后进程还在？
常见现象不是命令错了，而是信号没起效——这恰恰说明进程在正常响应。
-
kill默认发 SIGTERM（15），进程可以捕获并延迟退出（比如等请求处理完） - 如果几秒后还没退出，再试
kill -9；别刚敲完就怀疑命令失效 - 检查是否真有这个 PID：
kill -0 12345（不发终止信号，只检测进程是否存在，返回 0 表示存在） - 确认进程状态：
ps -o pid,stat,comm -p 12345，看到Z是僵尸进程（kill对它无效，得杀父进程） - 某些守护进程会自动重启（比如 systemd 管理的服务），
kill后立刻复活，得用systemctl stop xxx
批量杀进程时最容易忽略什么？
脚本或管道组合看似方便，但边界条件常被忽略。
-
ps aux | grep myapp | grep -v grep | awk '{print $2}' | xargs kill—— 如果myapp出现在日志或配置路径里，会被误杀 - 更稳妥的写法：
pgrep -f "myapp" | xargs -r kill（-r防止空输入报错） - 加
-i交互确认：killall -i myapp，避免手抖输错名字 - 别在生产环境跑无提示的
killall -9：比如killall -9 python会干掉所有 Python 进程，包括监控脚本、定时任务
killall 和 pkill 的模糊匹配，往往比信号本身更容易引发连锁反应。
