workerman协程处理短连接变慢的根本原因是同步阻塞操作拖垮调度或资源未释放占用事件循环；需确认协程启用、替换阻塞调用为异步版本、限制并发协程数、关闭长连接保活、设置进程级连接上限。
Workerman协程处理大量短连接时响应变慢、CPU打满、连接堆积，根本原因是协程调度被同步阻塞操作拖垮，或事件循环被未释放的资源持续占用。
确认是否真在用协程模式
第一步：检查启动脚本顶部是否引入了协程运行时。Workerman 5.0默认不启用协程，必须显式加载事件循环驱动。
第二步：运行php start.php status，查看输出中是否有event-loop: revolt或event-loop: swoole字样。若显示event-loop: select，说明仍在用传统阻塞式轮询，协程根本没生效。
第三步：确认onMessage回调内是否使用了await语法或go()函数。如果全是file_get_contents()、sleep()、mysqli_query()这类同步调用，协程已被绕过，实际退化为单线程串行处理。
替换所有阻塞调用为协程兼容版本
方法一：HTTP请求 → 改用workerman/http-client
安装：composer require workerman/http-client；在onMessage中创建Client实例后直接await $client->get(...)。原生file_get_contents()会挂起整个事件循环，而协程客户端只暂停当前协程，不影响其他连接。
方法二：MySQL查询 → 切换到workerman/mysql
【必须预热连接池】在onWorkerStart里初始化$db = new Workerman\Mysql\Connection(...)，而非每次请求都新建连接。否则每秒数百次TCP握手+SSL协商+认证，直接压垮服务端SYN队列。
方法三：文件读写 → 改用Workerman\IO\AsyncFile或stream_socket_client配合yield（需搭配Revolt驱动）
同步fopen()在高并发下极易触发系统级文件描述符耗尽，且磁盘IO会彻底冻结事件循环。异步文件操作虽不能完全避免延迟，但至少不会阻塞其他协程。
限制单Worker并发协程数防雪崩
第一步：在Worker初始化时设置最大协程数：$worker->property['max_coroutines'] = 100;
第二步：在onMessage开头加入限流判断：if (count($worker->coroutines) >= $worker->property['max_coroutines']) { $connection->close(); return; }
第三步：为每个协程任务设置超时：try { $result = await timeout(3.0, $promise); } catch (Throwable $e) { /* 记录并关闭连接 */ }
不做限制时，突发流量可能瞬间拉起数千协程，内存暴涨、调度开销剧增，最终导致OOM或事件循环卡死。100是保守值，可根据内存和CPU实测调整。
关闭不必要的连接保持机制
短连接场景下，ConnectionManager的长连接保活逻辑反而成负担。在onConnect回调末尾显式调用$connection->destroy();，强制释放连接资源。
Workerman默认对TCP连接做心跳探测，但短连接不需要维持状态。不主动销毁会导致连接对象滞留内存，协程无法GC，积累数万连接后内存泄漏明显。
启用Worker进程级连接数硬限制
在Worker配置中加入：$worker->max_connection = 2048;
这个参数作用于进程级别，当该Worker已建立连接数达到2048时，新连接会被内核拒绝（RST），避免单个Worker因连接过多而耗尽内存或陷入调度风暴。数值需结合ulimit -n和可用内存计算，通常设为系统文件描述符上限的70%。
