Workerman 5.x 协程需严格验证 event-loop 类型（revolt/swoole/swow）、正确选择驱动写法、升级依赖至指定版本并规避 onWorkerStart 中的协程误用，否则协程失效或进程卡死。
Workerman 5.x 协程新特性在 PHP 8.1+ 环境下释放了高并发潜力，但直接套用旧版写法极易触发 silent fail、进程卡死或 eventLoop 降级回 select——比如把 v4 的 Swoole 配置原封不动挪到 v5.1，服务启动后看似正常，实则协程根本未生效，所有 await 调用退化为同步阻塞。
确认协程驱动是否真正启用
第一步：启动服务后立即检查控制台输出的 event-loop 行，不是看有没有“OK”，而是看具体值。
第二步：执行 php start.php start（必须前台启动，禁用 -d 参数），观察日志中 WORKERS 表格里的 event-loop 列——合法值只有 revolt、swoole、swow 三者之一；若显示 select 或 event，说明协程未激活，后续所有协程写法均无效。
第三步：验证代码级协程能力，在 onMessage 中写入 Coroutine::create(fn() => var_dump(get_current_coroutine()));，若输出 object(Coroutine)#xxx，说明协程上下文已就位；若报错 Call to undefined function Coroutine::create()，代表 autoload 未加载或 eventLoop 配置被忽略。
按驱动类型选择对应写法
方法一：Swoole 驱动（需已安装 swoole 扩展）
设置 $worker->eventLoop = Workerman\Events\Swoole::class; 后，PHP 原生阻塞函数（如 file_get_contents、curl_exec）会被自动协程化，可直接 await 使用——这是唯一支持「自动协程化」的驱动。
方法二：Swow 驱动（需已安装 swow 扩展）
设置 Worker::$eventLoopClass = \Swow\EventLoop::class; 并 Worker::$timerInterval = 0;；【file_get_contents 等函数不会自动协程化，必须改用 Swow\Http\Client 或 Swow\Socket】，否则整个协程调度器将被阻塞。
方法三：Fiber 驱动（仅需 revolt/event-loop）
设置 $worker->eventLoop = Workerman\Events\Fiber::class;；此驱动不依赖任何扩展，但 【所有 I/O 操作必须使用 workerman 官方协程组件（如 workerman/http-client、workerman/mysql）】，混用原生函数等于主动放弃协程。
绕过 Composer 依赖陷阱
第一步：执行 composer require workerman/workerman:^5.1.0，不要写 ^5.0——5.0.x 存在 Fiber 驱动下 Timer::sleep 不触发协程切换的 bug，该问题在 5.1.0 正式修复。
第二步：若项目已存在 workerman/mysql，升级至 ^2.0.0；旧版 1.x 在 Swoole 驱动下可能因连接池复用逻辑缺陷导致 query() 返回 null。
第三步：禁用所有非 workerman 官方维护的协程包（如 easyswoole/pool、mix/redis），它们与 Workerman 5.x 的 revolt 基建存在事件循环冲突，会导致 onMessage 回调永不执行。
规避 onWorkerStart 中的协程误用
① 不要在 onWorkerStart 里直接 await 任何操作——该回调运行在主协程中，await 会阻塞 worker 进程初始化，导致后续连接无法接入。
② 若需预热数据库连接池，改用 Timer::add(0.1, fn() => $db->query('SELECT 1'), null, false); 延迟执行，确保 worker 已进入事件循环再触发协程任务。
③ 禁止在 onWorkerStart 中调用 Coroutine::create() 启动长期运行协程——Workerman 会在每次 fork 新 worker 时重复执行 onWorkerStart，造成协程数量指数级增长，最终耗尽内存。
