【面试锦囊】Swoole 如何优雅地处理致命错误

Swoole 开发中，异常和错误的处理一直是绕不开的“硬骨头”。不少开发者遇到过这样的困惑：明明写了 try-catch，为什么协程里的异常就是抓不到？Worker 进程明明崩了，为什么日志里没有任何有效信息？今天我们就直接把这些痛点拆开揉碎，聊聊 Swoole 中优雅处理致命错误的正确姿势。

协程里 throw 的异常，为什么 try-catch 捕不到？

根本原因在于 Swoole 的协程是独立调度单元——throw 和 try/catch 必须在同一个协程内部。一旦跨协程，异常就像被扔进了黑洞，协程退出时只能报出 Fatal error: Uncaught RuntimeException，说破天也没用。

很多人会犯这个错误：把 try 包在 SwooleCoroutine::create() 外面，指望外层能兜住内部协程的异常。这实际上是误解了协程的边界。

• 正确做法是：每个 go() 或 SwooleCoroutine::create() 内部必须自带 try/catch，别偷懒
• 协程生命周期结束时，尚未被捕获的 Throwable 会直接转化为致命错误——没有例外
• 特别留意 Co::sleep()、Co::mysql->query() 这类可能抛出底层异常的调用，它们最容易被忽略

Worker 进程崩溃时，怎么捞到致命错误信息？

workererror 事件虽然能感知进程退出，但它只能拿到退出码和信号，具体错误内容完全看不到。真正能抓住致命错误（如 E_ERROR、E_PARSE）的，是 register_shutdown_function + error_get_last() 这套组合拳。

关键点来了：这段逻辑必须在 workerstart 回调里注册。如果只写在全局位置，它只会对主进程生效，Worker 进程根本不管用，等于白写。

• 检查 $error['type'] 是否落在 [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR] 范围内
• 日志里必须包含 $error['file'] 和 $error['line']，否则找到错误也定不了位，白忙一场
• shutdown 函数里别做耗时操作，比如写文件、发 HTTP 请求这些。最佳实践是只记录或写入内存缓冲区，然后走异步刷盘

set_exception_handler 和 set_error_handler 能覆盖所有场景吗？

不能。这两个函数只对当前 PHP 生命周期有效。Swoole 的 Worker 进程是长生命周期，每次 workerstart 后都得重新注册一遍，不然它们就像过期药一样没有效力。

更要命的是：set_error_handler 默认不处理 E_ERROR 这类致命错误。要想拦截完整，必须与 register_shutdown_function 配合，二者缺一不可。

• 推荐的做法是：在 workerstart 中一次性注册 set_exception_handler、set_error_handler 和 register_shutdown_function，三件套配齐
• set_error_handler 里建议统一 throw new ErrorException，把异常流归集到一处处理，这样逻辑更清晰
• 别在这些处理器里调用 exit 或 die——它们会打断 Worker 进程的重启流程，后患无穷

max_request 设为 0 真的安全吗？

答案很明确：不安全。设为 0 意味着禁用自动重启，一旦出现内存泄漏或资源未释放，Worker 进程会越跑越慢，最终 OOM 或卡死。更糟糕的是，这时候连 workererror 都不会触发——因为进程并没有“崩溃”，只是“瘫痪”了，Swoole 根本感知不到异常。

max_request 是防内存泄漏的最后一道软性闸门：

• 生产环境建议设在 5000–10000 之间，具体数值取决于单请求的内存增长情况
• 配合 worker_num 做压测，观察 RSS 的增长趋势来定值，不要拍脑袋
• 如果业务中大量使用 static 变量或全局缓存，这个值要更保守一些

说到底，真正优雅的致命错误处理，靠的不是“捕获住”，而是“不让它发生”+“发生后快速隔离”。协程内部必须自带 try/catch，Worker 启动时三件套缺一不可，max_request 必须设一个合理的上限——这三点只要漏掉任何一点，一次小错误就随时可能演变成服务雪崩。