在 Swoole 4.1.0 及更高版本中，exit(0) 并非传统意义上的“安全退出”机制，它不会直接终止整个进程，而是抛出一个 SwooleExitException——该异常仅影响当前协程。若未在顶层 go() 或事件回调中使用 try/catch 捕获该异常，它将一路向上抛至 Swoole 底层，触发协程调度器中断。此时，Worker 进程可能仍在运行，但该协程的上下文已被销毁，后续逻辑全部丢失。
常见的高频问题场景包括：
- 在协程内调用
exit(0)后，HTTP 接口返回空响应或超时，而日志中未记录任何错误信息。 - 先执行
co::sleep()再调用exit()，导致进程卡死，无法响应新请求。
因此，实际建议非常明确：
- 必须在
go()包裹的最外层添加try/catch捕获SwooleExitException。 - 避免在
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（表示命令未找到），便不再启动同类进程。
常见易错点：
- 传入负数或大于 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和系统日志，三者交叉验证才能确保可靠。
