PHP 8.2 下 Swoole 协程提升吞吐量的关键是全局启用 Hook（swoole.enable_coroutine=On + swoole.hook_flags=SWOOLE_HOOK_ALL）、复用客户端、合理配置协程数与 Worker 数，并禁用无效的 JIT 优化。
PHP 8.2 下 Swoole 协程提升接口吞吐量，核心不是“开协程”，而是让 I/O 等待不卡住整个请求链路——关键在 Hook、复用和调度控制。
协程必须显式启用且全局 Hook 才生效
PHP 8.2 默认不开启 Swoole 协程 Hook，swoole.enable_coroutine=Off 是常见默认值。即使你写了 go()，没开启 Hook 就只是普通同步调用，file_get_contents、mysqli_query、cURL 这些函数依然阻塞。
必须在 php.ini 中明确配置：
extension=swoole.so swoole.enable_coroutine=On swoole.hook_flags=SWOOLE_HOOK_ALL
注意：SWOOLE_HOOK_ALL 包含 DNS、MySQLi、PDO、cURL、Redis 等，但不包含 sleep() 或 usleep()（需改用 Co::sleep()）；若只用 MySQL，可缩小为 SWOOLE_HOOK_MYSQLI | SWOOLE_HOOK_PDO 减少开销。
立即学习“PHP免费学习笔记（深入）”；
避免在协程里 new 大对象或重复创建客户端
协程轻量，但对象实例仍占内存。高频接口中反复 new Swoole\Coroutine\Http\Client 或 new Swoole\Coroutine\MySQL 会触发频繁 GC，拖慢吞吐。
推荐做法：
- HTTP 客户端：用连接池管理，或至少复用单个
$client实例（注意并发安全，get()是协程安全的，但不能跨协程共用同一实例做并发请求） - MySQL：使用
Swoole\Coroutine\MySQL并设置set(['timeout' => 3])，避免慢查询拖垮整个协程栈 - Redis：优先用
Swoole\Coroutine\Redis，而非 phpredis 扩展（后者未被 Hook，仍阻塞）
错误示例：go(function () { $redis = new Redis(); $redis->connect(...); ... }); —— 这里 connect() 不走协程，会阻塞。
协程数上限和栈大小直接影响并发稳定性
swoole.max_coroutine 默认是 3000，看似够用，但在 PHP 8.2 + 高频小请求场景下，若每个协程平均占用 4KB 栈空间，3000 个就是约 12MB 内存/进程。超出后新协程创建失败，go() 返回 false，但无报错提示，请求就卡死或超时。
建议根据压测结果调整：
- 先设为
8000，配合SWOOLE_HOOK_STACK_SIZE=8192（单位字节），观察 RSS 内存增长 - 若出现
coroutine stack overflow错误，说明递归或深层回调耗尽栈，需检查是否误在协程内用了未 Hook 的同步函数 - 线上环境建议搭配
swoole.display_errors=Off，避免协程错误泄露敏感路径
别忽略 Worker 进程数与 CPU 核心数的匹配
协程再快，Worker 进程数太少也会成为瓶颈。Swoole 默认 worker_num = 1，单进程跑所有协程，无法利用多核。
正确配置方式（以 4 核服务器为例）：
$server = new Swoole\Http\Server('0.0.0.0', 9501);
$server->set([
'worker_num' => 4,
'task_worker_num' => 2,
'max_coroutine' => 6000,
]);
注意：worker_num 不宜超过物理核心数；若业务含较多 CPU 密集操作（如 JSON 解析、加密），可略高于核心数，但要监控 top 中的 %CPU 和 %WAIT，避免调度争抢。
真正容易被忽略的一点：PHP 8.2 的 JIT 编译对协程无加速效果，它只优化 CPU 密集型代码路径，而协程价值恰恰在 I/O 密集——所以别寄希望于开 JIT 来“自动提升协程性能”。
