pcntl扩展未启用或函数不存在的最常见原因是环境配置错误：需确认PHP编译时启用了--enable-pcntl、运行时pcntl.enabled=1且未被禁用，CLI下用php -m | grep pcntl验证；Web服务器中启用无效且危险；Docker镜像如php:alpine需手动安装php-pcntl；信号处理必须声明declare(ticks = 1)或调用pcntl_async_signals(true)（PHP 7.1+），且须在注册信号处理器前执行；子进程fork后必须exit()避免指数级进程泄漏；SIGCHLD未处理会导致僵尸进程堆积，应通过pcntl_waitpid(-1, $status, WNOHANG)非阻塞轮询或正确注册并循环wait回收；忽略SIGCHLD不可靠，不建议作为主要方案。
pcntl扩展未启用或函数不存在直接报错
最常见的情况是脚本一运行就提示 Call to undefined function pcntl_fork() 或 pcntl_signal() not found。这不是代码写错了，而是环境没配好。
必须确认两点：pcntl 扩展已编译进 PHP（--enable-pcntl），且运行时未被禁用（pcntl.enabled=1）。CLI 模式下可通过 php -m | grep pcntl 快速验证；若无输出，说明扩展未加载。
- Web 服务器（如 Apache/Nginx + PHP-FPM）中启用 pcntl 是危险且无效的——它会被忽略或引发
Broken pipe (errno=32)类错误 -
php.ini中显式设置pcntl.enabled=Off会彻底屏蔽所有 pcntl 函数，即使扩展存在也报错 - 某些 Docker 镜像（如
php:alpine）默认不带 pcntl，需手动安装apk add php-pcntl并确保模块启用
declare(ticks = 1) 缺失导致信号不触发
PHP 的信号处理依赖 ticks 机制调度回调，漏掉 declare(ticks = 1) 就等于关掉了信号接收开关——哪怕注册了 pcntl_signal(SIGTERM, ...)，进程也完全收不到信号。
这个声明必须出现在信号处理器注册之前，且作用域覆盖到信号可能到达的执行路径（比如主循环内）。不要只在函数开头写一次，而要确保整个长期运行的逻辑块都受 ticks 控制。
立即学习“PHP免费学习笔记（深入）”；
- PHP 7.1+ 可改用
pcntl_async_signals(true)替代 ticks，但需注意：该函数必须在任何pcntl_signal()调用前执行，且不能在 Web 环境下调用 - 如果用了
pcntl_async_signals(true)却仍不响应信号，大概率是调用顺序错了，或被其他扩展（如 Xdebug）干扰 - ticks 值设为 1 是常规做法；设得过大（如 100）会导致信号延迟甚至丢失
子进程 fork 后未 exit 导致逻辑失控
调用 pcntl_fork() 后，父子进程共享后续全部代码路径。若子进程不主动 exit()，就会继续执行父进程的循环、再 fork、再进循环……最终创建出指数级子进程，迅速耗尽系统资源。
典型错误模式是：在 foreach 中 fork，却把 exit() 写在了条件分支外或遗漏了。
- 标准写法必须是：
if ($pid === 0) { /* 子进程逻辑 */ exit(0); }——exit()不可省略，也不能用return - 子进程中不要复用父进程的数据库连接、Redis 实例等资源；它们不是独立拷贝，而是共享 fd，容易引发并发冲突或连接中断
- fork 后立即调用
posix_setsid()（守护进程场景）或pcntl_sigprocmask()（信号隔离）前，务必先确认自己处于子进程上下文
SIGCHLD 未处理导致僵尸进程堆积
子进程退出后，内核会保留其退出状态，直到父进程调用 pcntl_wait() 或 pcntl_waitpid() 回收。否则，这些“已死但未收尸”的进程会变成僵尸进程（Z 状态），长期运行的服务会越积越多。
不能依赖信号自动清理——虽然 SIGCHLD 会在子进程终止时发送，但 PHP 默认不处理它，也不会自动 wait。
- 推荐在父进程中加一个非阻塞轮询：
pcntl_waitpid(-1, $status, WNOHANG)放在主循环里，每次检查是否有子进程结束 - 若使用
pcntl_signal(SIGCHLD, ...)注册处理器，必须在 handler 内部循环调用pcntl_waitpid(-1, $status, WNOHANG)，因为单次调用只能回收一个子进程 - 忽略
SIGCHLD（pcntl_signal(SIGCHLD, SIG_IGN)）在部分系统上可自动清理僵尸进程，但并非所有 Unix 变种都支持，不建议作为主要方案
信号处理本身不复杂，难的是父子进程职责边界、资源生命周期和异步事件调度的协同。最容易被忽略的是：子进程退出后父进程是否真回收了，以及信号是否真的抵达了目标进程——这两点不验证，多进程服务上线后大概率悄无声息地泄漏资源或拒绝关闭。
