装 event 扩展是 workerman 高并发不卡死的底线配置，否则单进程难撑几百连接；启用后 cpu 降 40%，吞吐量提升 3–5 倍，因 libevent 将 o(n) 轮询优化为 o(1) 内核事件通知。
装 event 扩展不是“可选优化”，而是 Workerman 在高并发场景下不卡死的底线配置。没它，单 Worker 进程通常撑不过几百连接；装了且生效，10k 并发下 CPU 占用能降 40%，吞吐量实测提升 3–5 倍。
为什么默认的 select 驱动撑不住并发
Workerman 启动时若没检测到 event 扩展，会自动回退到 PHP 内置的 stream_select 实现——它本质是线性轮询所有 socket 文件描述符（FD），时间复杂度 O(n)。连接数一过 500，每次循环都要遍历全部 FD，CPU 花在等待和扫描上，真正处理业务的时间反而被挤压。
- Linux 下
select最大支持约 1024 个 FD（受FD_SETSIZE限制），超出直接失败 - macOS / Windows 上更差，
poll或select在 1k+ 连接时延迟就明显抖动 - 日志里看到
select-1.0.0或poll-1.0.0就说明没走 event
event 扩展怎么让性能翻倍
event 是 libevent 的 PHP 封装，它把底层 epoll（Linux）或 kqueue（macOS）的事件通知机制暴露给 PHP。Workerman 检测到后，自动切换驱动，事件分发从 O(n) 变成 O(1) 级别响应。
- 不再轮询，而是靠内核回调：socket 就绪时，内核直接通知 PHP，省掉所有无效扫描
- 单进程轻松维持 5k–20k 长连接，前提是
Worker::$maxConnection和系统ulimit -n也同步调大 - 定时器（
addTimer）、信号处理、SSL 握手等也都跑在同一个高效循环里，不会额外开线程或进程
装了 event 却没生效？常见断点
装完 event.so 不等于就启用了——Workerman 只在启动瞬间检测一次，且依赖链严格。
- 系统没装
libevent库：Linux 执行pkg-config --modversion libevent，必须 ≥ 2.0.22；macOS 用brew install libevent，别用 MacPorts - PHP 多版本共存时，
pecl install event用错了php-config，导致扩展编译进错 SAPI（比如装进了 cli 却没装进 fpm） - Workerman 是常驻进程：
php start.php restart不够，必须php start.php stop && php start.php start才会重新加载扩展 - 日志第一行没出现
event-2.0.0类字样，只看到select→ 说明根本没加载成功，先查php -m | grep event
真正卡住并发的，往往不是 event 装没装，而是装了但没被 Workerman 检测到，或者业务代码在 onMessage 里偷偷执行了 sleep()、PDO 查询、file_get_contents() 这类同步操作——event 解决的是 I/O 等待，不是业务逻辑阻塞。
