选Swoole还是ReactPHP/Amp取决于项目瓶颈：Swoole需编译扩展、支持多进程与自动Hook，适合高并发混合负载；ReactPHP/Amp为纯PHP包、部署简单但单线程事件循环，适合I/O密集型轻量场景。
选 Swoole 还是 ReactPHP/Amp，关键不在“哪个更好”，而在于你当前项目卡在哪——是卡在安装部署、调试排查，还是卡在并发压不上去、CPU 利用率上不去。
为什么 Swoole 必须编译扩展而 ReactPHP 只需 composer require
Swoole 是 C 语言写的 PHP 扩展，必须通过 pecl install swoole 或源码编译加载进 PHP 内核；ReactPHP 和 Amp 都是纯 PHP 实现的 Composer 包，composer require react/http 就能直接用。这意味着：
- 你在 CI/CD 流水线里部署 Swoole 服务时，得确保所有机器都装了对应版本的
swoole.so，且 PHP 版本、ZTS（线程安全）配置必须匹配，否则PHP Warning: PHP Startup: Unable to load dynamic library 'swoole'会反复出现 - ReactPHP 在 Docker 中启动快：基础镜像用
php:8.3-cli，一行composer install就完事；Swoole 镜像得额外加apt-get install libssl-dev php-dev等构建依赖 - Amp 同样走 Composer 路线，但它默认启用协程，对 PHP 版本要求更严（最低 8.1），且某些函数（如
sleep()）在协程上下文中会被自动替换为非阻塞版——这点容易引发本地测试正常、线上行为异常的问题
Swoole\Coroutine::create() 和 React\EventLoop\Factory::create() 的调度本质不同
两者都叫“协程”或“异步”，但底层机制完全不是一回事：
-
Swoole\Coroutine::create()启动的是真正的用户态协程，由 Swoole 自己的调度器管理，可挂起/恢复任意同步函数（包括file_get_contents()、mysqli_query()），只要它们被 Swoole Hook 过 -
React\EventLoop\Factory::create()创建的是单线程事件循环，所有异步操作必须显式返回Promise，比如$client->get()；你不能在里面直接写sleep(1)，也不能调用未封装成 Promise 的第三方 SDK - Amp 的
Amp\async()表面类似 Swoole 协程，实际仍基于事件循环 + Promise，只是语法糖更厚；它不自动 Hook 原生函数，所以curl_exec()这类阻塞调用依然会卡住整个 loop
高并发场景下 Worker 进程数与 EventLoop 实例数的实际影响
这不是配置项数字大小的问题，而是资源模型的根本差异：
立即学习“PHP免费学习笔记（深入）”；
- Swoole 的
worker_num设为 8，就真启 8 个独立进程，每个都能跑满一个 CPU 核，适合混合型负载（比如同时做 API 返回 + 图片缩略 + Redis 写入） - ReactPHP 默认只有 1 个
EventLoop实例，全靠单线程轮询 I/O 事件；即使你 fork 出多个进程（用pcntl_fork），每个进程还得自己维护 loop，共享状态（如连接池、缓存）得额外处理 - Amp 支持多 loop（
Amp\Loop\run()可嵌套），但生产环境极少这么用；它的并发优势集中在 I/O 密集型任务，一旦有 CPU 密集操作（如 JSON 解析大数组、正则匹配长文本），整个 loop 就会被拖慢
真正容易被忽略的点是错误传播路径：Swoole 协程内未捕获的异常只终止当前协程，不影响其他请求；ReactPHP 的 Promise 链中一旦 reject 没被 catch()，loop 就可能静默退出；Amp 则会在未处理 rejection 时抛出 Amp\CancelledException 并终止当前 fiber —— 这些差异在压测时才暴露，但日志里往往只有一行 Segmentation fault 或空 panic。
