【考点归纳】Swoole 的各种进程退出状态码面试点-Swoole-PHP中文网

swoole 4.1.0+ 中 exit(0) 不等于安全退出，因其抛出 swoole\exitexception 而非终止进程，若未在顶层 try/catch 捕获，会导致协程上下文销毁、逻辑丢失、接口空响应或超时。

【考点归纳】swoole 的各种进程退出状态码面试点

为什么 `exit(0)` 在 Swoole 协程里不等于“安全退出”

在 Swoole 4.1.0+ 中，exit(0) 不会直接终止整个进程，而是抛出 Swoole\ExitException，但这个行为只对当前协程生效。如果没在顶层 go() 或事件回调里 catch 它，异常会冒泡到 Swoole 底层，触发协程调度器中断——此时 Worker 进程可能仍在运行，但该协程上下文已销毁，后续逻辑丢失。

常见错误现象：

协程里写 exit(0) 后，HTTP 接口返回空或超时，日志里看不到报错
用 co::sleep() 后紧跟 exit()，结果进程卡住不响应新请求

实操建议：

必须在 go() 包裹的最外层 try/catch 捕获 Swoole\ExitException
不要在 onReceive、onRequest 等回调内部裸写 exit()，应改用 return 或抛出自定义异常
若需退出整个 Worker，调用 $server->stop($worker_id)，而不是 exit()

`swoole_process::exit()` 的状态码怎么影响父进程判断

swoole_process::exit($status) 的 $status 值（0–255）会被父进程通过 swoole_process::wait() 拿到，存入 StatusInfo->exit_code。但注意：只有 $status !== 0 时，子进程才跳过 PHP 的 shutdown_function 和扩展清理流程，这会导致资源泄漏风险。

使用场景：

子进程执行完任务后主动退出，父进程根据 exit_code 判断是否重试
子进程因配置错误退出，父进程读到 exit_code === 127（命令未找到）就不再启动同类进程

容易踩的坑：

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

传入负数或大于 255 的值，实际被截断为 $status & 0xFF，比如 exit(300) 等价于 exit(44)
误以为 exit(0) 会触发 onWorkerStop——它不会，onWorkerStop 只响应 $server->stop() 或进程被信号杀死
子进程用了 exit(1)，但父进程 wait() 后没检查 StatusInfo->exit_code，导致失败静默

Worker 进程退出后，`exit_code` 和 `signal` 哪个更可信

当 Worker 进程退出，StatusInfo->exit_code 和 StatusInfo->signal 都会记录退出原因，但优先级不同：signal 更底层、更真实；exit_code 是上层封装，可能被覆盖。

例如：

进程被 kill -9 $pid 杀死 → signal === 9，exit_code 通常为 0（系统不保证）
代码里调用 exit(123) → exit_code === 123，signal === 0
OOM Killer 杀掉进程 → signal === 9，exit_code 不可依赖

实操建议：

监控脚本中，先查 signal 是否非零，非零就立刻告警“疑似被信号终止”
仅当 signal === 0 时，再信任 exit_code 做业务逻辑判断（如重试、降级）
用 dmesg -T | grep -i "killed process" 辅助验证 signal === 9 是否由 OOM 引起

如何从 `start.php status` 输出里快速定位异常退出

执行 php start.php status 后，GLOBAL STATUS 区域的 exit_status 列是关键线索。它不是单次退出码，而是该 worker_name 最近一次退出的 exit_code；exit_count 表示该状态码累计发生的次数。

典型问题模式：

exit_status: 255 + exit_count 持续增长 → 很可能是 PHP 解析错误（E_PARSE）或扩展初始化失败
exit_status: 0 但 exit_count > 0 → 进程被正常 stop 或 exit(0) 触发，需结合日志确认是否预期行为
exit_status: 137 → 几乎肯定是 OOM Killer 干的（128 + 9），不是代码问题

注意点：

start.php status 读的是共享内存里的快照，若进程刚退出还没来得及刷新，可能看到旧值
PROCESS STATUS 里的 pid 对应的进程若已不存在，说明它退出后没被 Manager 重建（可能 max_request 耗尽或配置了 reload_async = false）
别只盯 exit_status，同步查 error_log 和系统日志，三者交叉验证才可靠