EventLoop是Workerman每个Worker进程持续运行的主循环，基于epoll/kqueue等I/O多路复用机制监听socket事件，事件就绪时立即调用onConnect、onMessage等回调，全程非阻塞、无轮询、不新建线程；装event扩展可使吞吐量提升3–5倍，前提是系统已安装libevent且扩展正确加载并被Workerman实际启用。
EventLoop 是事件循环，不是“轮询”或“定时检查”，而是基于系统级 I/O 多路复用（如 epoll、kqueue）的非阻塞事件分发机制；Workerman 默认不依赖 PHP 的 event 扩展，但装了它能显著提升高并发下的事件处理吞吐量——前提是你的系统已安装 libevent 库。
EventLoop 在 Workerman 里到底干啥？
它不是后台偷偷跑的“定时任务”，而是每个 Worker 进程启动后持续运行的主循环：监听所有 socket 文件描述符（FD），一旦有连接就绪、数据可读、对端关闭等事件发生，立刻调用你注册的 onConnect、onMessage 等回调。整个过程不阻塞、不新建线程、不 fork 子进程。
关键点：
- Workerman 自动选择最优底层：有
libevent用它，没有就退到select（性能差很多） - 所有回调函数必须快进快出；如果在
onMessage里执行sleep(1)或同步 MySQL 查询，整个 Worker 就卡住，其他连接全被拖慢 - 定时器（
addTimer）也靠 EventLoop 驱动，不是靠pcntl_alarm或轮询
为什么装 event 扩展能提性能？
PHP 的 event 扩展是 libevent 的封装，提供更精细的事件控制和更低的调度开销。Workerman 检测到它存在时，会自动切换到该驱动，比默认的 stream_select 实现快 3–5 倍（实测 10k 并发下 CPU 占用下降约 40%）。
装之前先确认系统级依赖：
- Linux 上运行
pkg-config --modversion libevent，输出版本 ≥ 2.0.22 才行 - macOS 用
brew install libevent，别用 MacPorts（容易版本错乱） - Windows 下不建议装，Workerman 官方未测试，且
libevent在 Windows 上行为不稳定
然后编译扩展：
pecl install event
并在 php.ini 中加入：
extension=event.so
装完怎么验证是否生效？
启动 Workerman 后，看日志第一行：
- 看到
event-2.0.0或类似字样 → 成功启用event扩展驱动 - 只看到
select或poll→ 还在用默认回退方案，检查extension=event.so是否加载、libevent是否可被动态链接器找到（ldd $(php-config --extension-dir)/event.so | grep libevent） -
php --ri event输出中 “Libevent Version” 字段为空 → 扩展加载失败，常见原因是libevent路径不在LD_LIBRARY_PATH或/etc/ld.so.conf.d/里
容易被忽略的兼容性细节
Workerman v4+ 和 v5+ 对 event 扩展的 ABI 兼容性不同：
- v4.x 支持
event扩展 2.x 和 3.x（但 3.0.0b1 以上需打 patch） - v5.0+ 要求
event≥ 3.0.8，否则EventBuffer::read()可能返回空字符串 - 如果你用的是 Swoole 兼容层（
workerman-swoole），别装event扩展——它和 Swoole 的事件驱动冲突，会直接 crash
真正影响性能的从来不是“有没有装”，而是“装了之后有没有让 Worker 进程实际用上”。别只看 php --m 里有没有 event，得看 Workerman 启动日志和压测 QPS 曲线。
