PHP 协程：把“排队等结果”变成“边等边干活”

传统 PHP 处理单个请求像餐厅里按顺序点单的顾客：前一道菜没上齐，后一位只能干等着。遇到数据库慢查询或第三方接口响应延迟，CPU 直接 idle 空转，并发一高，服务器压力全砸在网络 I/O 上。协程的出现，就是把这种“死等”模式升级成用户态下的协作式并发模型。它不依赖操作系统线程切换，单进程即可流畅调度数千个任务，核心逻辑仅一行：任务挂起时交出控制权，有结果时自动恢复现场。

协程的底层依托于 PHP 的生成器（Generator）。当代码执行到耗时 I/O 节点，框架拦截并触发 yield，当前函数的执行栈被完整封存，事件循环立刻切入下一个就绪任务。等底层 socket 读就绪或异步回调完成，运行时再精准还原断点继续往下跑。整个过程没有上下文切换的系统开销，内存占用维持在极窄区间。

在 PHP 生态里落地协程，本质是重构I/O 交互习惯。写业务链路时，把串行调用拆成并行分支是最直观的切入点。比如同时拉取用户画像、历史订单和实时库存，传统写法只能一层层套回调或 Promise，协程环境里直接并发发起请求，统一阻塞等待集合返回。代码结构从螺旋上升变成扁平流程，异常捕获和日志追踪也顺着常规同步逻辑走，调试难度直线下降。

真正容易踩坑的，是“伪异步”带来的连锁阻塞。不少开发者认为套上协程注解就能无视性能，结果混入原生 PDO::query 或未封装的 cURL 同步调用，整个事件循环瞬间被钉死。破局方案很直接：严格划清异步边界。数据库查询替换为支持多路复用的驱动包，HTTP 客户端绑定 epoll 或 kqueue 事件源，Redis 走管道批量命令。老项目中大量残留的同步库，建议部署到独立 Worker 进程中，通过消息队列与协程主层通信，既保全存量资产，又不污染高并发主干。

协程对资源的消耗集中在状态栈的频繁创建与销毁。长连接或高频短任务的场景下，容易出现句柄泄漏或内存水位线抬升。日常编码需养成按需实例化、显式清理的习惯，遇到批量聚合任务提前划定协程上限，利用框架提供的并发控制原语做流量削峰。不要盲目追求“无限并发”，把协程数量压在单机文件描述符限制的安全阈值内，稳定性会明显提升。

协程并不改写 PHP 逐行执行、弱类型的语言底色，它提供的是事件驱动下的流程编排容器。起步阶段不必死磕极端压测数据，先跑通一个“异步读取+并行计算+同步落盘”的闭环用例，摸清事件循环的调度边界与异常传播路径。等到真实流量灌进来，面对库存扣减校验、多维度报表聚合这类重网络 IO 的场景，你自然会知道该把异步杠杆搭在哪根梁上。切换协作思维，PHP 服务才能平稳跨越 I/O 瓶颈，稳稳接住高并发冲击。