swoole协程异常无法跨协程传播，必须在每个go()内层独立try-catch捕获\throwable并记录日志、清理资源；worker致命错误需通过workererror事件、register_shutdown_function及swoole日志兜底；全局用set_exception_handler和set_error_handler补漏；zookeeper异常需显式捕获或状态码判断。
在Swoole中，协程异常无法跨协程传播，父协程用try-catch包住go()调用根本捕获不到子协程抛出的RuntimeException或LogicException，直接导致协程静默退出甚至Worker进程崩溃——必须按运行边界分层拦截。
协程内部必须自行捕获异常
每个go()启动的协程都需独立包裹try-catch，这是唯一可靠方式。Swoole不会把子协程异常向上冒泡，漏写就等于放弃控制权。
第一步：在go回调函数最外层加try-catch块，且必须捕获\Throwable而非Exception，否则Error类错误（如ParseError、FatalError）会被跳过。
第二步：catch分支中调用error_log()记录完整堆栈，至少包含$e->getMessage()、$e->getTraceAsString()和协程ID（Co::getuid()）。
第三步：执行必要清理，比如关闭协程HTTP客户端、释放Channel资源；若使用Co::defer注册清理逻辑，需确保defer回调在catch之后仍能触发——【defer注册必须在try块内完成，否则catch后不会执行】。
Worker进程级致命错误兜底
当语法错误、内存耗尽或未定义函数调用等致命错误发生时，try-catch完全失效，Worker会直接退出。此时依赖Swoole事件机制和PHP底层钩子。
方法一：监听server的workererror事件，在进程退出前获取exit_code和signal，用于区分OOM、段错误或信号终止。
方法二：在workerstart回调中调用register_shutdown_function，配合error_get_last()提取最后致命错误信息；注意仅对E_ERROR/E_PARSE/E_CORE_ERROR/E_COMPILE_ERROR四类生效，其他错误类型不触发shutdown。
方法三：启用Swoole内置日志，配置log_file和log_level=5，确保所有WARNING及以上级别错误落盘；但该日志不含协程上下文，不能替代业务层主动记录。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
全局异常与错误处理器补漏
作为最后一道防线，覆盖那些逃逸出协程和Worker范围的异常，比如onStart/onShutdown钩子中的逻辑错误。
设置set_exception_handler捕获未被任何try-catch拦截的Exception和Error实例，记录trace_id（若已生成）、当前时间、进程PID及错误堆栈。
同时注册set_error_handler，将E_WARNING/E_NOTICE等转为异常抛出，再由上述异常处理器统一处理——这能避免因忽略警告导致后续逻辑错乱。
【务必在Swoole Server启动前注册这两个处理器，否则worker进程继承的是PHP默认行为】。
ZooKeeper等第三方客户端异常专项处理
与ZooKeeper交互时，网络抖动或会话超时会抛出ZookeeperException，但其继承自Exception而非Throwable，常规catch(\Throwable)可能遗漏。
方法1：显式catch(ZookeeperException $e)，检查$e->getCode()是否为Zookeeper::ZCONNECTIONLOSS或Zookeeper::ZSESSIONEXPIRED，触发重连逻辑。
方法2：使用ZooKeeper客户端的setExceptionHandler，传入闭包接收$type、$state、$error参数，比try-catch更早介入连接层异常。
方法3：调用exists()、get()等API后，不依赖异常，而是先判断返回值是否为Zookeeper::ZOK；非ZOK时查状态码分支处理，规避异常开销。
