worker_num需按CPU核数和业务类型科学配置：IO密集型设为核数×2，CPU密集型设为核数或+1～2；必须验证ps进程数、合理设置task_worker_num，并压测监控内存与协程峰值。
要让Swoole服务在真实业务中既不浪费资源又不卡死请求，worker_num不能拍脑袋填个数字——它直接决定常驻PHP进程数量，每个进程独占内存、加载全部类与扩展，设错一步就可能引发OOM或调度抖动。
先确认你的业务类型
IO密集型（如API聚合、LLM网关、Redis/MySQL同步调用多）和CPU密集型（如图像处理、大文本正则、同步计算）对worker_num的敏感度完全不同。前者靠并发等待释放CPU，后者靠真刀真枪榨干核心。如果业务里混用阻塞式cURL、未设超时的PDO查询、或同步写日志，那它本质上就是IO密集型，哪怕代码写着“异步”也白搭。
这一步不能跳过。误判类型会导致后续所有配置失准。
按CPU核数定基准值
第一步：执行nproc命令查出服务器物理CPU核心数（不是线程数）。例如返回8，那就以8为基准。
第二步：IO密集型服务设为CPU核数 × 2，即16；CPU密集型保守设为CPU核数 或 +1～2，即8或9～10。8核机器配16个worker是安全起点，超32必须压测+监控内存水位，否则容易触发OOM或调度抖动。
【注意：worker_num不是并发连接数放大器，而是CPU密集任务的并行上限】。它管的是能同时跑多少个“主循环”，不是能接多少个TCP连接。
验证实际生效值
改完配置后，不要只信代码里的数字。必须执行ps aux | grep php，数清楚当前存活的worker进程数（排除master和manager进程）。systemd或supervisor可能拦截reload导致配置未生效，此时看到的还是旧进程数。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
这一步漏掉，等于没调。
结合task_worker_num做隔离
方法一：如果你有模型推理、邮件发送、大文件转码这类耗时操作，必须启用task_worker——它用独立子进程隔离阻塞逻辑，防止卡住worker事件循环。task_worker_num建议设为worker_num × 0.5～1，上限不超过worker_num × 2。
方法二：若不用task功能，就把task_worker_num彻底删掉或设为0，避免manager进程无谓创建空task进程，白白吃掉进程号和基础内存开销。
【关键前提：一旦设置task_worker_num ≥ 1，就必须注册onTask和onFinish两个回调，否则启动失败】。
压测时盯紧两个指标
① 内存增长曲线：用free -h或cat /proc/meminfo观察RSS是否随worker_num线性飙升。每个worker在大项目中常占40–80MB，64个worker轻松吃掉3GB以上。
② 协程峰值数：调用swoole_get_status()看coroutine_peak_num是否逼近max_coroutine。接近就说明协程密度已到临界点，该调高max_coroutine或优化协程内阻塞逻辑，而不是继续加worker_num。
这一步做完，进程数就真正落地了。
