僵尸进程无法被proc_terminate杀灭，因其已终止仅剩内核表项；php父进程必须通过pcntl_waitpid()或注册sigchld信号处理器及时回收，否则在fpm长连接场景下持续累积。
proc_open 启动的子进程变成僵尸，不是 proc_terminate 能解决的——它根本没用，因为 proc_terminate 只杀“活”进程，而僵尸早已退出。
proc_terminate 对僵尸进程完全无效
调用 proc_terminate($process) 时，PHP 会向目标进程发送信号（如 SIGKILL）。但僵尸进程（Z 状态）已终止，内核中只剩一个待回收的进程表项，没有执行上下文，无法接收任何信号。此时 proc_terminate 会静默失败或返回 false，proc_get_status($process)["running"] 仍为 true（因资源未释放），容易误判。
- 僵尸进程的 PID 在
ps aux中显示状态为Z，命令列带<defunct></defunct> -
kill -9 $pid对僵尸无效，系统返回No such process -
proc_close($process)也无法清理僵尸，它只关闭管道、等待进程退出——而僵尸“不退出”，它已经退完了
真正该操作的是父进程，不是子进程
proc_open 创建的子进程，其父进程就是当前 PHP 进程（即你的脚本或 fpm worker）。只要 PHP 进程还在运行，且未处理子进程退出，僵尸就会一直挂着。关键不是“怎么杀僵尸”，而是“PHP 怎么及时回收”。
- 确保 PHP 进程注册了
SIGCHLD信号处理器：pcntl_async_signals(true); pcntl_signal(SIGCHLD, function() { pcntl_waitpid(-1, $status, WNOHANG); }); - 若使用
pcntl_fork自行管理子进程，必须配对调用pcntl_waitpid()或pcntl_wait()，不能只靠proc_close - 在 CLI 模式下，主脚本退出时，所有子进程被 init 收养并自动清理；但在 PHP-FPM 场景中，worker 进程长期存活，必须主动回收，否则僵尸越积越多
- 不要用
signal(SIGCHLD, SIG_IGN)，虽能自动清理，但丢失退出码和错误信息，不利于调试
Windows 下 proc_terminate 的行为差异要特别注意
Windows 不支持 POSIX 信号，proc_terminate 默认发送 CTRL_BREAK_EVENT，且仅对控制台程序有效。如果 proc_open 启动的是非控制台程序（如 Python 脚本、curl.exe），或命令被 cmd.exe 包了一层（如 cmd /c "php script.php"），proc_terminate 实际作用对象是 cmd.exe，而非真实目标进程——目标进程变成孤儿，最终可能残留为僵尸（Windows 称为“挂起进程”，表现类似）。
- 启动命令时避免 shell 包装：直接写
["php", "script.php"]，而不是"php script.php" - 检查
proc_get_status($process)["pid"]返回的是否是预期进程 PID，而非 cmd.exe 的 PID - Windows 上更可靠的做法是：用
taskkill /PID %d /F配合proc_get_status获取的 PID 手动清理（需注意权限）
最易被忽略的一点：proc_open 启动的进程若本身又 fork 出子进程（比如某些 shell 脚本、Java 应用），PHP 只能 wait 它的直系子进程，那些孙子进程退出后若未被中间进程回收，也会变成僵尸——这已超出 PHP 控制范围，需从被调用程序自身逻辑修复。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
