PHP 协程实际应用中的性能与陷阱分析

PHP 从 5.5 开始引入生成器和协程，真正让普通开发者开始大规模实践协程，还是靠 Swoole、Hyperf、Amp 这些成熟方案驱动的。传统 PHP-FPM 每个请求一个进程，同步阻塞 IO，并发全靠进程数堆，内存占用高且 CPU 空转严重。协程能在一个进程内模拟出大量并发任务，在 IO 密集场景下吞吐量提升明显。但实际落地协程，远不是“用了就快”那么简单。我见过不少项目在上线后遇到诡异卡顿、数据错乱、甚至连接池崩溃，最后都指向协程使用方式不对。这篇文章就结合真实场景，聊聊协程带来的性能红利，以及那些容易被忽略的陷阱。

协程带来的性能红利

协程的核心价值在于通过非阻塞 IO 和主动让出，把等待时间还给其他任务。传统同步模型下，一次 Redis 查询耗时 1ms，进程就空闲 1ms；协程模型下，这个等待可以被其他协程用起来，CPU 资源充分利用。在 Swoole/Hyperf 这类常驻内存框架中，协程可以创建数十万个，而每个协程仅占用几个 KB 内存，相比 PHP-FPM 动辄几十 MB 的进程开销，差别巨大。

我做过一个压测对比：同样是一台 4 核 8G 的机器，PHP-FPM 处理一个模拟耗时 50ms 的 MySQL 查询，最大并发约 200，而用了 Swoole 协程后，单进程内并发轻松到 5000+，系统负载反而更平稳。对于大多 API 接口、消息推送、网关代理的 IO 密集型业务，协程几乎是性能瓶颈的最优解。

陷阱一：阻塞调用会让整个服务“假死”

协程在 PHP 中是单进程内协作式调度，一个协程阻塞，就代表整个进程内所有协程都阻塞。最常见的坑就是协程里用了 `sleep()`、`file_get_contents()`、`curl` 扩展的同步请求，或者直接调用 `PDO` 默认同步模式。比如硬编码 `sleep(1)` 模拟延迟，结果压测时发现所有请求都排队延迟 1 秒。

解决办法是使用协程化的 IO：Swoole 的 `Coroutine\Http\Client`、`co::sleep()`，或者框架自带的连接池与异步客户端。很多新手会直接写 `sleep()`，看起来没区别，但线上流量一上来就会引发灾难。务必在代码规范里约定：协程环境下禁止使用同步阻塞函数。

陷阱二：协程不是多线程，CPU 密集反而更慢

协程切换也需要栈分配、上下文保存和恢复，这些开销比普通函数调用高。如果业务主要是大数组遍历、加解密、图像处理这类纯 CPU 计算，协程并不能加速，反而因为频繁切换导致性能下降。更危险的是，一个协程出现死循环，整个进程都会卡死，其他协程没有任何机会抢占 CPU。

针对 CPU 密集任务，正确做法是用 Swoole 的多进程模块（如 `Swoole\Process`）或者独立微服务来分片处理，保持主协程进程干净。不要指望协程能并行计算，它顶多算“协作式并发”，不是“并行”。

陷阱三：全局变量与静态变量会串数据

协程模式下，同一个进程内会有多个执行流交叉运行，如果随意使用全局变量、静态变量、实例属性来保存请求上下文，就可能发生数据串包。最常见的是在控制器里用一个 `$userId` 静态属性存储用户信息，两个协程切换后，第二个协程读到了第一个用户的 ID。

解决思路是使用协程上下文管理器，或者依赖框架提供的 `Context` / `Coroutine::getContext()`，把数据绑定在协程 ID 上。业务代码里尽量不要用全局变通。另外还要注意事务边界：一个连接上同时跑多个事务，必须使用连接池从独立连接中获取，否则事务会交错提交。

陷阱四：异常与调试变得很“反直觉”

协程的调用栈会被“切断”，一旦抛出异常，打印出来的栈可能只有当前函数，看不到是哪个上游协程发起的调用。特别是结合异步回调中的异常，经常出现“错误捕获了但找不到源头”的情况。

调试时建议启用框架的协程追踪特性，比如 Swoole 的 `request_uri` 和 `trace_id` 上下文贯穿，或者记录 `cid`。同时一定要写严格规范的超时异常和连接池失败重试逻辑，避免协程长期挂起导致内存泄漏。内存泄漏也是个隐蔽问题：常驻进程下，某个协程异常退出后如果引用没有被释放，会逐级累积，最终 OOM。上线前务必做长时间稳定性压测，并用 `ps` 和监控工具观察内存曲线。

写在最后

协程给 PHP 带来了逼近 Go 风格的并发能力，但代价是编程思维和基础设施的全面升级。它适合 IO 密集型场景，不适合无脑替代现有架构。实际应用中，先定义好阻塞边界，严格使用协程化客户端，隔离上下文，设计好异常链路，再配合多进程补足 CPU 能力，才能真的把性能红利吃到嘴里。踩坑不可怕，怕的是把协程当“银弹”，最后被并发打趴了还找不到原因。