Swoole yield协程调度与自动调度的区别

关于Swoole中的yield协程调度，有几个核心判断需要明确：在现代版本（4.1+，尤其是5.0）中，手动编写yield已属于过时的半协程模型。默认启用的是自动调度机制，通过swoole_runtime::enableCoroutine() Hook标准函数实现I/O自动挂起，开发者完全不需要显式使用yield。

答案非常明确：两者并非同一概念。

为什么要如此强调这一点？

Swoole 4.x早期为何需要手动yield

Swoole 4.0初期，协程调度器刚刚落地，部分I/O Hook尚未完善。当时开发者经常需要显式调用SwooleCoroutine::yield()或在generator函数中使用yield主动让出控制权。这种写法本质上是“半自动”状态：调度器虽然存在，但切换点需要开发者手动指定。

• 这种手动yield常见于go(function () { ... SwooleCoroutine::yield(); ... })这类老式启动方式
• 与PHP原生yield混用时极易混淆：yield在generator中用于返回值，在协程中却只是挂起——但两者上下文完全不互通
• 一旦漏掉yield，CPU密集型循环会彻底阻塞整个协程线程，导致其他协程全部卡住
• 无法与co::sleep()、CoChannel::pop()等原生协程API统一调度逻辑

自动调度的工作原理

从Swoole 4.1版本起，通过swoole_runtime::enableCoroutine()启用运行时Hook后，所有受支持的标准函数（比如file_get_contents、curl_exec、mysqli_query、sleep）在协程中调用时，都会自动触发挂起——无需编写任何yield。

挂起时机由底层引擎决定：I/O阻塞、定时器到期、显式co::sleep()等。协程栈（含C栈）会完整保存，恢复时能精确回到函数中间某一行，并非简单重跑整个函数。调度器基于事件循环驱动，依靠reactor和timer管理就绪队列，而不是轮询。go()启动的协程默认采用自动调度，无需包装成generator，也不依赖yield关键字。

混用yield与自动调度的常见陷阱

最常见的错误是将旧文档中的generator协程写法直接套入新环境，结果既无法实现并发效果，又难以调试。

• 写go(function () use ($ch) { yield $ch->pop(); })：PHP会将其解析为generator，但go()并不执行generator对象，实际没有任何协程运行
• 在已启用swoole_runtime::enableCoroutine()的环境下还调用SwooleCoroutine::yield()：可能造成双重挂起或调度紊乱，尤其在嵌套协程中
• 用foreach (some_generator() as $v) { ... }包裹协程逻辑：generator自身不具备调度能力，里面的所有co::sleep()会立即抛出RuntimeException: Coroutine is not running
• 误以为yield能替代co::sleep(1)：前者不带时间语义，也不触发I/O Hook，纯粹是空挂起，无法实现延时效果

当前的最佳实践

除非你在维护Swoole 2.x/3.x等老旧项目，否则所有新代码都应彻底放弃手动yield。重点应放在以下三件事上：

• 入口必须调用swoole_runtime::enableCoroutine()（通常在执行Server->start()之前或Coroutinerun()内部）
• I/O操作统一采用协程版API：SwooleCoroutineHttpClient、SwooleCoroutineMySQL，或者依赖Hook的标准函数
• CPU密集型任务若确实需要让出控制权，应使用co::usleep(1)或co::sleep(0)，而不是yield或usleep()

一个容易被忽视的要点是：自动调度仅对“协程上下文内发起的调用”生效。如果在go()外部、或非协程启动的CLI脚本中调用file_get_contents，即使开启了enableCoroutine()，它依然是同步阻塞的。