workerman 5.2.3 自动适配最优i/o多路复用机制：linux用epoll、macos/bsd用kqueue、windows用select，无需手动配置；实际引擎可通过timer::getioengine()日志确认，前提是pcntl和posix扩展已启用。
你真正需要关注的，是确保运行环境满足底层依赖条件，而不是“配什么”。一旦条件齐备，Workerman 内部会无缝接管。
确保系统支持对应 I/O 机制
不同系统默认启用的底层引擎不同，但都依赖特定 PHP 扩展和内核能力：
-
Linux（推荐）：自动使用
epoll，需确保pcntl和posix扩展已启用（PHP 编译时默认开启，可通过php -m | grep -E "pcntl|posix"验证） -
macOS / BSD：自动回退到
kqueue，同样要求pcntl+posix；若缺失，会降级为select（性能明显下降） -
Windows：仅支持
select（无epoll或kqueue），这是内核限制，无法绕过；适合开发调试，不建议用于生产高并发场景
验证当前实际使用的底层
启动服务时加一句日志，就能看到 Workerman 自动选了哪个：
$worker = new Worker('websocket://0.0.0.0:2346');
$worker->onWorkerStart = function($worker) {
echo "I/O engine: " . \Workerman\Lib\Timer::getIOEngine() . "\n";
};
输出类似 epoll、kqueue 或 select，即为当前生效的底层。
不建议也不支持的手动指定
Workerman 5.x 不提供 public API 让用户强制指定 I/O 引擎（如早期版本曾有 Worker::$ioFactory）。强行修改源码或反射注入不仅破坏稳定性，还会在升级后失效。如果你发现它没按预期选型（比如 Linux 下跑出 select），说明：
- PHP 缺少
pcntl或posix扩展 - 运行在 Docker 容器中且未启用
--cap-add=SYS_PTRACE（极少数调试场景影响） - 用了某些精简版 PHP（如 alpine 上未装全扩展）
提升事件循环效率的关键点
比“换底层”更重要的是让事件循环本身更健康：
- 避免在
onMessage等回调里执行阻塞操作（如 file_get_contents、sleep、MySQL 同步查询） - 耗时逻辑务必投递到异步进程或消息队列（如 Redis + Worker 子进程处理）
- 连接数超 1000 时，Linux 需调大
ulimit -n（建议 ≥ 65535） - 多进程部署时，
$worker->count = 4是起点，实际值应略小于 CPU 核心数
