Swoole通过C扩展Hook同步函数实现协程调度，协程在I/O时自动挂起、go()创建、I/O完成或退出时销毁；ReactPHP依赖事件循环和Promise回调，需显式run()启动、链式调用，连接由事件循环统一管理。
Swoole 的 C 扩展级协程调度机制
Swoole 不是纯 PHP 实现，而是通过 C 扩展重写了 PHP 底层的 I/O 调度逻辑。它在内核层 Hook 了 fread、mysqli_query、file_get_contents 等同步函数，让它们在协程中自动挂起，而不是阻塞整个进程。
关键点在于：协程生命周期与 PHP 请求周期解耦。一个 Swoole\Http\Server 进程启动后长期运行，协程在 go() 调用时创建，在 I/O 完成或显式退出时销毁，连接句柄由协程私有持有——这意味着你不能在协程外访问 $client->body，否则会报 Undefined property: Swoole\Coroutine\Http\Client::$body。
常见踩坑点：
- 误把协程客户端当同步对象使用，比如在
go()外调用$client->get() - 未设置超时（
timeout）导致协程永久挂起，连接池耗尽 - 在协程中混用
sleep()（同步阻塞）而非Swoole\Coroutine::sleep()（非阻塞挂起）
ReactPHP 的纯 PHP 事件循环模型
ReactPHP 没有修改 PHP 内核，它依赖 stream_select() 或 libevent 封装的事件循环（React\EventLoop\ExtEventLoop），所有异步操作都基于回调或 Promise 链展开。
立即学习“PHP免费学习笔记（深入）”；
它的连接不是“协程独占”，而是由事件循环统一注册、监听、分发。例如 React\Http\Client\Request 发出请求后立即返回一个 Promise，后续逻辑必须写在 ->then() 或 ->otherwise() 中，否则拿不到响应体。
典型问题场景：
- 忘记调用
$loop->run()，整个异步流程静默卡住，无错误提示 - 在
then()回调里执行耗时同步操作（如json_encode大数组），阻塞事件循环，拖慢全部并发请求 - 误以为
React\Socket\Connector的connect()是同步方法，实际返回的是Promise，直接 echo 会输出object(React\Promise\Promise)
连接复用与资源回收方式差异
Swoole 协程连接是“即用即取、用完归还”：每次 go() 内部新建 Swoole\Coroutine\Http\Client，协程结束自动释放底层 socket；而 ReactPHP 的连接池（如 clue/reactphp-http 提供的 Pool）需要显式管理——$pool->acquire() 获取，$pool->release($connection) 归还，漏掉 release 就会导致连接泄漏。
这种差异直接影响稳定性：
- Swoole 在高并发下更容错：协程崩溃，连接自动清理；ReactPHP 若某次
acquire后没release，该连接就永远卡在池中 - ReactPHP 的连接池可配置最大空闲数、TTL，Swoole 则靠
max_idle_time和协程超时双重控制 - 两者都不支持跨进程共享连接句柄——别试图把 Swoole 的
Client实例传给子进程，也别在 ReactPHP 的不同Loop实例间传递 socket 资源
协程切换开销与调试可见性
根据 2026 年 5 月实测数据，Swoole 单次协程切换耗时约 1.42 μs，而 ReactPHP 的 Promise 链式调度平均耗时 3.91 μs。这不是因为 ReactPHP 写得差，而是它每一步都要构造新 Promise 对象、触发回调注册、等待事件循环轮询——这些在 PHP 用户态完成，天然比 C 层协程挂起/恢复重。
但代价是：Swoole 的协程堆栈在 debug_backtrace() 中不可见（被 C 层调度器截断），出错时只能看到顶层 go() 调用；ReactPHP 的 Promise 链则完整保留在 PHP 调用栈里，var_dump($e->getTrace()) 能清晰看到每个 then() 的嵌套层级。
所以真实项目里：
- 高频短任务（如 API 聚合）优先选 Swoole，省掉 Promise 构造和回调跳转开销
- 需要强可调试性、团队 PHP 经验浅、或需与现有同步代码渐进集成时，ReactPHP 更稳妥
- 别迷信“协程一定比 Promise 快”——如果业务逻辑本身是 CPU 密集型，两者都会卡在同一个 PHP 解释器线程里，此时瓶颈根本不在调度层
