swoole协程饥饿源于协作式调度下cpu密集型逻辑无法主动让出，须在server启动前调用swoole\coroutine::set(['enable_preemptive_scheduler'=>true])启用抢占式调度，且php需zts编译。
协程饥饿不是配置没开全，而是 CPU 密集型逻辑在默认协作式调度下根本得不到轮转机会——Swoole 4.4+ 必须显式启用抢占式调度才能缓解。
为什么 go() 启动的协程会“饿死”
默认调度只在 I/O 阻塞点（如 Co::sleep()、Co\Http\Client->get()）让出控制权。一旦某个协程陷入纯计算循环（比如大数组遍历、base64_decode 长文本、正则反复匹配），它就一直霸占当前 Worker 线程，其他协程无法切入。
- 现象：并发请求中部分响应极慢甚至超时，
strace -p $pid显示线程持续在用户态执行，无系统调用 - 原因：Swoole 协程是协作式（cooperative），不是操作系统级抢占式（preemptive）
- 关键限制：PHP 层无原生 tick 注入能力，
declare(ticks=1)仅对当前文件生效，无法覆盖require进来的业务代码
Swoole\Coroutine::set(['enable_preemptive_scheduler' => true]) 怎么用才生效
这个配置必须在协程环境启动前设置，且仅对后续创建的协程起作用。放在 onRequest 或 go() 内部调用完全无效。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 正确位置：Server 启动前，例如
Swoole\Coroutine::set()放在Swoole\Coroutine\run()外层或onStart回调里 - 依赖条件：PHP 编译需开启
--enable-maintainer-zts（ZTS 线程安全模式），否则调度器无法注入时钟中断 - 注意副作用：开启后每个协程每 10ms 强制检查一次是否超时（可调），带来约 3%~5% 的 CPU 开销，但换来响应时间毛刺消除
- 验证方式：压测时观察
server->stats()['coroutine_num']是否稳定，饥饿协程不再长期卡在SWOOLE_COROUTINE_STATUS_RUNNING
比抢占式调度更实用的规避策略
与其依赖底层调度器硬切，不如从代码结构上减少长耗时同步计算。很多所谓“CPU 饥饿”其实是设计层面可避免的。
- 把大循环拆成带
co::sleep(0)的微任务：每次处理 100 条数据后主动让出，既保持逻辑连贯又释放调度权 - 将密集计算移出协程：用
$server->task()投递到 TaskWorker 进程，避免阻塞整个 Worker - 慎用
openssl_encrypt/mb_convert_encoding等隐式高开销函数：它们不触发 I/O，也不受 Hook 影响，极易成为饥饿源 - 用
pcntl_fork()不可行：Swoole Worker 进程已脱离 PHP-FPM 模式，fork 会破坏事件循环和协程上下文
真正难处理的不是“怎么开抢占”，而是识别哪些函数表面看是纯计算、实则内部有未暴露的 I/O 或信号等待——比如某些扩展的 curl_setopt() 在特定参数下会触发 DNS 查询，而该查询若未被 SWOOLE_HOOK_CURL 覆盖，就会静默阻塞。这类边界情况必须靠 strace + lsof -p 组合定位，不能只盯 PHP 代码。
