Workerman并发卡在几百的主因是未启用event扩展、系统连接限制未调优及业务代码存在同步阻塞。需装event扩展、设Worker::$maxConnection、调高ulimit和somaxconn，并确保onMessage中无同步操作。
Workerman并发量卡在几百上不去，先看是不是没装event扩展
Workerman默认用PHP的stream_select做IO复用，这是阻塞式轮询，连接一多就撑不住——哪怕CPU、内存都空着，QPS也上不去。装event扩展后能切到epoll（Linux）或kqueue（macOS），单进程轻松扛几千连接。
检查方法：php -m | grep event，没输出就得装。别信“PHP版本高就自带”，它从来不是核心扩展，必须手动编译或用pecl install event。
- CentOS/RHEL：先装
libevent-devel，再pecl install event，确认extension=event.so写进了php.ini - Ubuntu/Debian：装
libevent-dev，再pecl install event；注意PHP多版本共存时，要用对应phpize和php-config - 装完重启
php-fpm或Web服务器无效——Workerman是常驻进程，必须停掉所有php start.php start再重新启动
开了event还是并发不涨？查Worker::$maxConnection和系统限制
Workerman自己设了连接数上限，默认是1000，但这个值常被忽略。同时Linux内核也有ulimit -n（单进程文件描述符上限）和/proc/sys/net/core/somaxconn（全连接队列长度）两道坎，任一个卡住，新连接就会被丢弃或超时。
- 在启动脚本里显式设置：
Worker::$maxConnection = 20000;（放require_once之后、Worker::runAll()之前） - 启动前执行：
ulimit -n 65535；生产环境要写进/etc/security/limits.conf，否则systemd服务会回落到默认1024 -
sysctl -w net.core.somaxconn=65535，并写入/etc/sysctl.conf持久化；否则SYN_RECV状态的连接堆积，客户端看到的是“连接拒绝”或“timeout”
用了event+调大限制，压测延迟却越来越高？小心onMessage里同步阻塞操作
event只解决IO等待问题，不解决业务逻辑卡顿。一旦onMessage里有file_get_contents、sleep、慢SQL、未加超时的cURL，整个事件循环就被拖住，后续请求排队，RT飙升，看起来像并发不足。
- 数据库务必用异步驱动（如
swoole_mysql或amphp/mysql），传统PDO或mysqli是同步阻塞的 - HTTP调用改用
Swoole\Coroutine\Http\Client或ReactPHP等异步客户端，禁用file_get_contents和curl_exec - 日志别直接
file_put_contents，用Monolog配StreamHandler+BufferHandler缓冲，或转到syslog/UDP发出去
为什么event扩展在Docker里总加载失败？路径和权限容易漏
Docker镜像里pecl install event看似成功，但php -m找不到，大概率是.so路径不对，或者容器启动时php.ini没加载到扩展配置。
- 用
docker exec -it xxx php --ini确认加载的php.ini路径，然后检查该文件是否包含extension=event.so；很多Alpine镜像默认用/usr/local/etc/php/conf.d/docker-php-ext-event.ini - Alpine用户注意：
pecl install event依赖libevent，但apk add libevent装的是运行时库，编译时还得apk add libevent-dev - 如果用
php:alpine基础镜像，推荐直接用现成的扩展包：docker-php-ext-install event（部分PHP版本支持），比pecl更稳
真正卡并发的，往往不是Workerman本身，而是event没生效、系统限制没收、或者业务代码悄悄把异步变成了同步。这三块没对齐，调再多参数也没用。
