【面试避坑】Swoole 协程模式下的错误捕获 (try-catch)

先说几个核心判断：Swoole 协程模式下的错误处理，和传统 PHP-FPM 完全是两码事。很多人在面试或实际项目中踩的坑，归根结底就是一个——还在用同步思维写异步代码。这篇文章把几个关键点拆开讲透，希望能帮你避开那些“看起来正常，一上量就崩”的陷阱。

协程内必须自己 try-catch，父协程捕不到

协程是一个独立的调度单元，这意味着异常不会跨协程传播。很多新手会习惯性地在 go() 外层包一个 try-catch，觉得这样就能兜住所有子协程的异常——但事实是，子协程里 throw 出来的异常，外层完全捕获不到。它只会让子协程静默退出，最终触发一个 Fatal error: Uncaught RuntimeException。

正确做法也很简单：每个协程函数体开头，老老实实套上 try-catch。有几个细节需要注意：

• 别指望“外面包一层”来兜底，协程的隔离性决定了这种方式无效
• 哪怕你调用的只是一个封装好的函数，比如 doRequest()，也要在协程内部把它 try 住，不能指望函数内部自己能处理好
• 捕获的时候记得用 Throwable，而不是 Exception。否则 ParseError 这类 Error 类型的错误照样会逃逸出去

Worker 进程里的致命错误不能靠 try-catch

try-catch 对致命错误是无效的——E_ERROR、E_PARSE 这类错误一旦发生，Worker 进程会直接退出。主进程还在跑，但 Worker 已经挂了，表现出来就是“服务看似活着，请求却一批批失败”，排查起来极其头疼。

这种情况必须双管齐下：

• 在 $server->on('workerstart') 里注册 register_shutdown_function()，配合 error_get_last() 来捕获最后一次致命错误，拿到具体的文件行号
• 同时监听 $server->on('workererror') 事件，这个事件在 Manager 进程检测到 Worker 异常退出时会触发，能拿到 $workerId 和 $signal，方便定位是哪个 Worker 崩了
• 两者的日志建议分开记录，方便后续排查时快速定位问题根因

协程安全的 I/O 调用不报错，但不用协程客户端就等于埋雷

有一种情况特别坑：代码语法没问题，try-catch 也写了，但一压测就丢请求、数据错乱、CPU 突升。十有八九，问题出在你用了同步扩展。

这些调用表面上看不会抛异常，但它们会把整个协程调度器卡死：

• file_get_contents() → 应改用 Swoole\Coroutine\FileSystem::readFile()
• mysqli_query() → 必须换成 Swoole\Coroutine\Mysql::query()
• curl_exec() 或 Guzzle 同步模式 → 只能用 Swoole\Coroutine\HttpClient

协程化不是简单替换一个 autoloader 就完事了。整条调用链都得过一遍“协程适配检查表”，漏一个就全盘失效。

全局异常处理器只起兜底作用，别当主力

有人会注册 set_exception_handler() 或配置 Swoole\Coroutine::set(['hook_flags' => ...])，觉得这样就能一劳永逸。其实全局处理器只对未被捕获的异常生效，而且有一个致命缺陷——它拿不到协程上下文，比如当前的 $workerId、请求 ID 这些关键信息。

真正有用的异常处理，必须带上上下文：

• 在每个协程入口手动记录 Co::getuid() 或传入 request_id
• 把 $e->getTraceAsString() 和关键业务参数（如用户 ID、订单号）一起写进日志
• 避免在 catch 里做耗时操作，比如发邮件、远程写日志。用 Channel 异步投递更稳妥

还有一个最容易被忽略的点：协程退出前没做资源清理。就算 catch 住了异常，$client->close() 或 fclose() 也得在 finally 块里确保执行。连接泄漏比异常本身更难排查，别在这个地方留尾巴。