Workerman 5.2.3 和 Swoole 不能也不需要搭配安装；二者是定位不同、机制冲突的独立技术路线，共存会导致事件循环、信号处理等层面冲突，应根据需求二选一。
Workerman 5.2.3 和 Swoole 不能也不需要搭配安装。
它们是两条完全独立的技术路线，定位不同、实现机制冲突，强行共存不仅无益，反而容易引发运行异常。
Workerman 是纯 PHP 实现的常驻进程框架
它不依赖任何 C 扩展，靠 pcntl、posix 和原生 socket 函数就能启动。你执行：
composer require workerman/workerman php start.php start
就跑起来了——整个服务由 PHP 自己管理进程、监听端口、处理连接。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
Swoole 是 PHP 的 C 扩展，必须编译安装
它通过底层 epoll/kqueue 实现高并发，要求启用 swoole.so，且与 PHP-FPM 或 CLI 模式深度耦合。Swoole 启动的是自己的事件循环，和 Workerman 的主从进程模型互斥。
你无法在一个 PHP 进程里既用 Workerman 的 Worker::runAll()，又调用 Swoole\Http\Server ——两者都试图接管 event loop、信号处理、子进程生命周期，必然打架。
如果你看到“Workerman + Swoole”一起出现，通常只有两种情况：
- 误传概念：比如把 “Workerman 可选 Libevent 加速” 听成 “支持 Swoole”；或把 “Webman（基于 Workerman 的全栈框架）” 和 “Hyperf（基于 Swoole 的框架）” 混为一谈。
- 反向桥接场景（极少见）：用 Swoole 做接入层（如 WebSocket 网关），再通过 HTTP 或 Redis 把消息转发给 Workerman 处理业务逻辑——但这不是“安装搭配”，而是跨进程通信，属于架构设计，不是环境配置。
正确选择建议：
- 要快速上线、兼容老旧服务器（如 CentOS 6.5）、PHP 版本受限（如仅支持 7.2）、不想装扩展 → 选 Workerman 5.2.3
- 要极致性能、万级并发、已用 PHP 8+、运维能配合编译扩展、团队熟悉协程 → 选 Swoole 4.10+
- 不要试图让它们共存于同一服务进程，也不要在
php.ini里同时启用swoole.so和依赖 Workerman 的守护逻辑
简单说：不是“怎么搭配”，而是“选哪个”。
