PHP进程失控主因是僵尸进程未回收、Web服务器配置失当及后台任务失控；pcntl_waitpid需循环调用防漏收；proc_open比exec更可控；PHP-FPM宜按负载选static或dynamic模式，避免ondemand。
PHP 本身不擅长长期维持大量并发进程，所谓“进程太多”的问题，通常不是 PHP 主动创建了成百上千个 pcntl_fork() 进程，而是：
——子进程没被及时回收，ps aux | grep php 看到一堆 Z（僵尸）状态；
——Web 服务器（如 Apache 的 prefork、PHP-FPM 的 pm.max_children）配置失当，导致请求堆积、进程数飙升；
——用 exec() / shell_exec() 启动后台任务却未加控制，反复 fork 出孤立进程。
立即学习“PHP免费学习笔记（深入）”；
为什么 pcntl_waitpid(-1, $status, WNOHANG) 必须循环调用
单次 pcntl_waitpid() 只能回收一个已终止的子进程。若同时有 5 个子进程结束，只调用一次就会漏掉其余 4 个，它们变成僵尸进程，持续占用 PID 和内核资源。
- 必须在主循环或信号处理器中持续轮询：
while (pcntl_waitpid(-1, $status, WNOHANG) > 0) { /* 清理 */ } - 不能只在
pcntl_signal(SIGCHLD, ...)回调里调用一次——Linux 信号不排队，多个SIGCHLD可能被合并为一个，导致漏收 - 如果主进程是阻塞式（比如监听 socket），建议用
pcntl_signal_dispatch()配合pcntl_signal(SIGCHLD, ...)，并在每次循环开头手动触发 dispatch
proc_open() 比 exec() 更可控的三个原因
直接用 exec("xxx &") 启动后台命令等于放养：无法获取 PID、无法判断是否启动成功、无法强制终止。
-
proc_open()返回资源句柄，可配合proc_get_status()实时查进程状态（running / stopped / exited） - 通过
$pipes数组能重定向 stdin/stdout/stderr，避免子进程因管道满而卡死 - 可用
proc_terminate($proc, SIGTERM)+proc_close($proc)安全收尾，比kill -9更温和，也避免孤儿进程
PHP-FPM 的 pm 模式选 static 还是 dynamic？看负载特征
这不是性能参数的“越大越好”问题，而是进程生命周期管理策略的选择。
-
pm = static：固定数量 worker（如pm.max_children = 50），适合 CPU 密集型、请求耗时稳定的服务；缺点是空闲时也占内存，突发流量会直接 502 -
pm = dynamic：按需伸缩（pm.start_servers、pm.min_spare_servers、pm.max_spare_servers），适合 I/O 密集、请求时长波动大的场景；但频繁 fork/exec 有开销，且pm.max_children必须设合理上限，否则仍可能打满内存 - 真正危险的是
pm = ondemand：请求来才拉起进程，但高并发瞬间可能因拉起太慢而丢请求，且每个请求都经历一次进程初始化，PHP 扩展加载、OPcache 预热全失效
进程失控往往不是代码写错了，而是没意识到 PHP 进程模型和 Unix 进程语义之间的缝隙——比如信号不可靠、僵尸必须主动收、FPM 的 pm 参数影响的是整个池而非单个请求。盯住 /proc/ 里的 State 和 PPid，比看 top 数字更准。
