swoole的wait和waitpid是协程安全封装接口，均阻塞当前协程而非进程；wait无参回收任一僵尸子进程，waitpid需指定pid并支持超时，但不支持waitpid(-1)批量回收。
wait 和 waitPid 在 Swoole 协程中根本不是系统调用
它们是 Swoole 封装的协程安全接口，底层仍调用 Linux 的 wait 或 waitpid，但行为受协程调度影响。关键点在于：Swoole 的 wait 和 waitPid 都是**阻塞当前协程**，而非阻塞整个进程（即不会卡住其他协程）。如果你误以为它们像 C 语言里那样直接映射系统行为，容易在超时、并发回收等场景踩坑。
wait() 只能回收任意一个已退出子进程
和 POSIX 的 wait 一致，Swoole 的 wait() 不接受 PID 参数，它会从内核就绪队列中取第一个可回收的子进程。常见错误是期望它“按 fork 顺序回收”或“回收刚 fork 的那个”，实际做不到。
- 返回值是子进程 PID，但无法反推是哪个子进程 —— 尤其当多个子进程几乎同时退出时
- 若没有子进程已退出，协程会挂起，直到有子进程状态变化（Zombie 状态产生）
- 不支持非阻塞模式，也没有
WNOHANG类似选项 - 典型适用场景：简单后台任务，父协程只关心“至少一个完成”，不关心具体是谁
waitPid() 支持指定 PID + 可选超时，但默认仍阻塞
Swoole 的 waitPid(int $pid, float $timeout = -1) 行为更接近 waitpid($pid, &$status, 0)，但它额外加了协程超时控制。注意：即使传了 $timeout = 0，它也**不是等价于 WNOHANG** —— 它只是让协程立即返回，但返回逻辑和系统 waitpid 不同。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
$timeout = -1：永久阻塞，直到指定 PID 的子进程退出 -
$timeout = 0：非阻塞轮询一次，子进程未退出则返回false（不是 0） -
$timeout > 0：最多等待指定秒数，超时返回false - 如果子进程已变成僵尸但尚未被任何 wait 类函数回收，
waitPid()能立刻拿到其状态；但如果子进程还在运行，它不会主动 kill 或干预
回收多个子进程必须循环调用，且不能靠一次 waitPid(-1)
Linux 系统里 waitpid(-1, ...) 等价于 wait，但 Swoole **没有提供 waitPid(-1) 这种用法**。它的 waitPid() 强制要求传入正整数 PID。这意味着：你 fork 了 5 个子进程，就必须显式调用 5 次 waitPid($pid)（或混用 wait()），没有批量回收接口。
- 常见疏漏：用
for ($i = 0; $i 回收，但没检查返回值是否匹配预期 PID，导致回收错乱或遗漏 - 更稳妥的做法是维护一个
$pids数组，在 fork 后记录每个子进程 PID，再遍历调用waitPid($pid)并校验返回值 - 协程环境下，别在循环里无休止
waitPid($pid, 0)轮询 —— 会浪费 CPU，应配合co::sleep(0.01)让出调度权
Swoole 的 wait 相关 API 表面简洁，但隐藏着系统调用语义与协程调度的双重约束。最容易被忽略的是：它不自动清理所有僵尸进程，也不保证调用顺序与 fork 顺序一致，真正健壮的回收逻辑必须自己管理 PID 生命周期和调用节奏。
