协程模式下回调自动运行于独立协程，支持await与协程I/O，实现真正并发；普通模式为同步顺序执行，阻塞函数会导致串行处理。
Workerman 5.x协程模式和普通模式的区别直接影响代码是否阻塞、并发能力是否达标、HTTP请求能否同步写法异步执行——不选对模式，file_get_contents()会卡死整个进程，100个连接变成串行处理。
协程模式下，每个回调自动运行在独立协程中
启用协程驱动（如Swoole/Revolt/Swow）后，Workerman会在每次触发onMessage/onConnect/onWorkerStart等回调时，自动创建一个新协程来执行该回调函数体。
这意味着：同一个Worker内，100个并发HTTP请求会各自拥有独立的执行上下文，互不抢占，也不阻塞彼此。
普通模式下，这些回调全部在主线程同步顺序执行——前一个请求调用sleep(3)，后面99个请求必须排队等满3秒才能开始。
协程模式支持await语法与协程客户端，普通模式不支持
方法一：使用workerman/http-client发起协程HTTP请求
安装组件：composer require workerman/http-client
在onMessage回调中直接写：$response = await $client->get('https://api.example.com');
这行代码在协程模式下是非阻塞的，底层自动挂起当前协程、让出CPU，等响应回来再恢复；在普通模式下，await语法根本无法解析，PHP报错ParseError。
方法二：使用原生Fiber协程手动调度
需先composer require revolt/event-loop:^1.0.0，再显式调用Coroutine::create()包裹耗时操作。
【普通模式下调用Coroutine::create()无效，不会创建协程，仅同步执行】
协程模式能自动协程化I/O，普通模式不能
第一步：确认当前使用的eventLoop驱动类型
查看$worker->eventLoop属性值，是Swoole::class、Revolt::class还是Swow::class
第二步：验证阻塞函数是否被协程化
Swoole/Swow驱动下，file_get_contents("http://...")会被自动转为非阻塞协程调用，无需改写；
Fiber驱动下，file_get_contents()仍是阻塞的，必须替换为workerman/http-client或curl_init + curl_exec协程封装版，否则会拖垮整个进程。
普通模式下，所有PHP内置函数都保持原生行为，不存在“自动协程化”概念。
协程模式要求严格规避同步阻塞函数
协程不是魔法，它只解决I/O等待问题。如果在协程回调里写for ($i=0; $i，这个CPU密集型循环会霸占协程调度权，其他协程无法切入。
普通模式对此无感——反正本来就是单线程同步跑，谁卡都一样卡。
协程模式下真正危险的是混合使用：比如在Swoole协程中调用未协程化的PDO::query()，或在Fiber协程里用fopen+stream_get_contents——【这些操作不会自动挂起，而是实打实阻塞当前协程，进而阻塞整个Worker进程】
