pcntl_fork()在父进程中返回子进程PID（正整数），在子进程中返回0，失败时返回-1；必须用if-else明确分流，子进程需立即执行任务并exit()，否则会重复执行后续代码导致进程爆炸。
PHP进程管理不是靠“学语法”就能上手的，它本质上是 Unix 进程模型在 PHP 中的映射，必须理解 fork、wait、信号和资源生命周期，否则写出来的多进程脚本大概率会漏回收、卡死、或在生产环境突然崩掉。
pcntl_fork() 返回值怎么判断父子进程
这是所有多进程逻辑的起点，但新手常误以为返回值是“子进程 PID”就代表“正在子进程中运行”——完全错误。
-
pcntl_fork()在父进程中返回子进程 PID（正整数），在子进程中返回0，失败时返回-1 - 必须用
switch或if/else if/else明确分流，不能只靠if ($pid > 0)就认为“进了父进程分支”，因为0和-1都会被这个条件跳过 - 子进程一启动就要立刻做自己的事，不要继续执行父进程后续逻辑；常见错误是忘记
exit()，导致子进程重复执行 fork 后面的代码，甚至再次 fork，形成进程爆炸 - 示例中看到
case 0: ... break;是安全写法，而if ($pid === 0) { ... exit(); }更直白可靠
为什么 pcntl_waitpid() 比 pcntl_wait() 更常用
因为实际项目里你几乎总要等特定子进程，而不是随便哪个退出都行。用 pcntl_wait() 容易造成“错收”：比如你 fork 了 A、B、C 三个子进程，B 先退出，pcntl_wait() 就把它收了，但你本意是等 A 完成后再处理结果。
-
pcntl_waitpid($pid, $status, WNOHANG)支持非阻塞轮询，适合主循环中监控多个子进程状态 -
WNOHANG参数很关键：不加它，pcntl_waitpid()会卡住直到目标进程退出；加了它，立即返回0（未退出）或pid（已退出），方便做超时控制 - 别依赖
pcntl_wait()做“自动回收全部”，它只收一个；要回收多个，得用循环 +pcntl_waitpid(-1, ...)（-1 表示任意子进程），但依然不如显式管理每个 PID 清晰 - 僵尸进程不是“偶尔出现”，而是只要父进程没调
wait类函数，子进程退出后立刻变僵尸——ps aux | grep 'Z'能直接看到
信号处理为什么不能只注册 SIGTERM
只监听 SIGTERM 看似够用，但实际部署中你会遇到更多信号场景，比如容器重启发 SIGHUP、运维手动 kill -USR2 重载配置、甚至 Ctrl+C 触发 SIGINT。
立即学习“PHP免费学习笔记（深入）”；
-
pcntl_signal()必须配合pcntl_signal_dispatch()使用（PHP 7.1+），否则信号可能被延迟甚至丢失；老版本需用declare(ticks = 1)，但 tick 开销大且难控 - 守护进程必须调用
posix_setsid()脱离终端，否则收到SIGHUP会直接退出——这不是 bug，是 Unix 设计使然 - 子进程里不要注册信号处理器，除非你明确需要它响应信号；父子进程信号处理是独立的，子进程继承的是信号掩码，不是 handler 函数
- 用
pcntl_async_signals(true)可开启异步信号，避免 tick 机制，但仅限 CLI 模式，Web SAPI（如 Apache、FPM）下无效
PCNTL 不是万能方案，什么情况下该换思路
PCNTL 只能在类 Unix 系统（Linux/macOS）工作，Windows 下完全不可用；而且它要求 PHP 编译时启用 --enable-pcntl，很多共享主机或容器镜像默认关闭。
- 如果你只是想“并行请求 API”，用
cURL multi或ReactPHP异步 HTTP 更轻量、更可移植 - 要做长期运行的后台任务（如日志分析、文件轮转），优先考虑
supervisord+ 多个独立 PHP 脚本，比自己 fork 管理更稳定 - 高并发实时服务（如聊天、推送），Swoole 的协程或进程池是更现代的选择，避免 fork 的系统开销和信号复杂度
- 哪怕坚持用 PCNTL，也别在 Web 请求中调用
pcntl_fork()—— FPM worker 是复用的，fork 后子进程可能污染父进程内存或连接池，极难调试
真正卡住人的从来不是 fork 怎么写，而是子进程退出后父进程有没有在正确时机、用正确方式调 waitpid；还有就是信号来了，你的 handler 是不是真被执行了——这两点不验证清楚，进程管理永远停留在“看起来能跑”。
