要让Swoole服务高并发不卡顿，必须启用Reactor+Worker+TaskWorker三层分工模型：Reactor仅负责网络事件分发，Worker执行业务逻辑并投递阻塞任务给TaskWorker，后者异步处理后回调；worker_num应设为swoole_cpu_num()获取的真实CPU核心数，并在onWorkerStart中初始化连接池，避免onTask中重复建连；通过htop、netstat和strace验证多进程与I/O效率。
要让Swoole服务在高并发下不卡顿、响应更快、单位时间内处理更多请求，必须让CPU核心全部动起来，而不是只靠单个进程硬扛。
理解Reactor+Worker+TaskWorker三层分工
启动Swoole服务时，默认就启用了多进程模型，但吞吐量上不去，往往是因为没让各层进程各司其职。Reactor线程只做网络监听和事件分发，它不处理业务；Worker进程负责执行HTTP/WS逻辑，一旦遇到数据库查询或文件读写就卡住；TaskWorker则专为这类阻塞操作而生——它从Worker手里接过任务，自己跑完再回调，Worker全程不等待。
这三类角色必须同时存在且数量合理，否则就会出现Reactor忙不过来、Worker全在等IO、TaskWorker闲置的失衡状态。
设置worker_num匹配物理CPU核心数
第一步：调用 【swoole_cpu_num()】 获取当前机器真实可用的核心数，不要手写固定值；
第二步：在Server配置中明确设置 'worker_num' => swoole_cpu_num()；
第三步：启动服务后用 ps aux | grep php 查看实际Worker进程数量是否与预期一致——少于该数说明配置未生效，常见原因是配置写在了onStart之后或被其他set覆盖。
如果worker_num设得太小，比如只有2个，而服务器有16核，那14个核心全程空转；设得太大（如64），反而引发频繁进程切换开销，响应延迟上升。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
启用TaskWorker并投递耗时任务
方法一：在Worker进程中调用 $server->task($data) 发送任务，数据会自动序列化并路由到空闲TaskWorker；
方法二：在onTask回调里执行阻塞操作，完成后用 $serv->finish($result) 返回；
方法三：在onFinish中接收结果并继续后续逻辑，注意此处不能直接echo或return，要走Swoole响应流程。
【务必在onWorkerStart里初始化数据库连接池或Redis连接，不要在onTask里每次new新连接】，否则TaskWorker每处理一次任务都新建连接，连接数爆炸，数据库直接拒绝服务。
验证多进程是否真正生效
运行 htop 或 top -Hp $(pgrep -f "php your_server.php")，观察是否有多个PHP进程持续占用不同CPU核心；
向接口发起100并发请求，用 netstat -anp | grep :9501 | grep ESTABLISHED | wc -l 确认连接数稳定增长而非堆积；
查看 strace -p $(pgrep -f "php your_server.php" | head -1) 输出，若大量出现 epoll_wait 而无长时间 read/write 阻塞，说明I/O已非瓶颈。
