Workerman协程与普通异步混用必然导致执行流崩溃。因Revolt协程调度器与libevent回调机制底层冲突，引发事件循环撕裂、上下文丢失、await卡死及连接资源错乱，三类典型错误包括阻塞调用、跨框架Promise复用和未await传递Promise。
Workerman协程和普通异步混用时，事件循环被撕裂、协程上下文丢失、await语句卡死、连接资源错乱——这些不是偶发异常，而是必然发生的执行流崩溃。
协程运行时与异步回调的底层冲突
Workerman 5.0默认使用Revolt事件循环，协程函数（如await $client->get()）依赖该循环的调度器维持上下文栈；而传统异步方式（如$connection->onMessage = function() { file_get_contents(...); }）直接触发PHP原生阻塞调用或注册libevent回调，完全绕过协程调度器。
一旦在同一个Worker实例中同时启用Worker::$eventLoopClass = \Workerman\Events\Swoole::class和手动调用stream_socket_client，Swoole协程运行时会尝试接管所有I/O，但libevent驱动的AsyncTcpConnection仍按非协程路径执行，导致【TCP连接对象在两个不兼容的事件循环中被并发操作】，轻则连接中断，重则进程段错误退出。
混用场景下的三类典型错误
方法一：在协程回调里调用阻塞函数
比如在onMessage中写sleep(1)或file_get_contents('http://...')——这会让当前协程挂起，但事件循环仍在调度其他协程，结果是该连接后续所有请求全部堆积，内存持续上涨直至OOM。
方法二：用普通异步组件复用协程连接池
例如把workerman/mysql创建的协程连接对象，传给基于ReactPHP的自定义异步查询封装——MySQL连接内部持有Revolt的Promise状态机，而ReactPHP试图用它的Deferred重新包装，【Promise链断裂，await永远得不到resolve】。
方法三：跨协程边界传递未await的Promise
写$promise = $db->select(...)->query();却不加await，直接把$promise塞进全局数组，等另一个协程去取——此时Promise尚未绑定到当前协程的执行栈，取出后调用await $promise会抛出InvalidStateError，因为该Promise从未被当前协程“声明所有权”。
正确隔离路径
第一步：确认整个Worker生命周期只使用一种事件驱动模型
要么全用Workerman 5.0内置Revolt协程（推荐），要么退回Workerman 4.x纯回调模式；禁止在同一个Worker中同时require workerman/http-client和手动new AsyncTcpConnection。
第二步：协程组件必须成套使用
选了workerman/mysql，就不要掺杂PDO长连接；用了workerman/http-client，就别再引入curl_init + curl_exec——所有I/O必须走同一套awaitable接口。
第三步：Worker启动前冻结事件循环类型
在require_once __DIR__ . '/vendor/autoload.php';之后、任何Worker实例化之前，立刻设置Worker::$eventLoopClass；若不显式指定，则Workerman 5.0自动选择Revolt，此时再动态切换为Swoole会导致【已初始化的协程运行时无法热替换，构造函数参数校验失败】，引发TcpConnection第3个参数为null的TypeError。
