hyperf 3.0 中 worker_num 已被移除，实际并发由 task_worker_num 和协程调度决定；应设 task_worker_num 为 cpu 核数×2～4、开启 task_enable_coroutine=true，并通过 max_conn 和 max_request 控制连接与请求生命周期。
Hyperf 3.0 中 worker_num 不再控制进程数
直接改 server.settings.worker_num 在 Hyperf 3.0 里无效——它已被移除。Hyperf 3.0 完全基于 Swoole 5+ 的协程 Server 模型，worker_num 是 Swoole 4 时代 Worker 进程的概念，而新版默认使用 SWOOLE_PROCESS 模式下的 task_worker_num + 协程调度，实际并发由协程数和 CPU 核心数共同决定，不是靠增减“Worker 进程”来提升吞吐。
真正该调的是 server.settings.task_worker_num 和 server.settings.task_enable_coroutine
如果你需要处理大量异步任务（如发短信、写日志、调第三方 API），核心是调整 Task Worker 的数量和行为：
-
task_worker_num：设为cpu_count * 2到cpu_count * 4较稳妥，过高反而因上下文切换拖慢性能 - 务必开启
task_enable_coroutine: true，否则 Task Worker 内无法使用协程客户端（如Co\Http\Client），容易阻塞 - 若任务本身轻量且纯 CPU 计算，可考虑降为
cpu_count；若含较多 I/O 等待，建议用cpu_count * 3
配置示例（config/autoload/server.php）：
'settings' => [
'task_worker_num' => 12,
'task_enable_coroutine' => true,
],
想限制并发连接数？看 server.settings.max_conn 和 max_request
很多人误以为改“进程数”能防爆，其实更关键的是连接与请求生命周期控制：
-
max_conn控制同时接受的 TCP 连接上限（默认10000），超限会直接拒绝新连接，适合应对突发流量 -
max_request控制每个 Worker 协程（注意：不是进程）处理多少请求后自动重启，默认0（不重启），设为1000–5000可缓解内存缓慢泄漏 - 这两个值比“进程数”对稳定性影响更直接，尤其在长连接或高并发场景下
验证是否生效？别只看 ps aux | grep http
Hyperf 3.0 启动后，ps 看到的进程数 ≈ 1（Master）+ 1（Manager）+ N（Task Worker），但没有传统意义上的 “Worker 进程”。正确验证方式：
- 启动时加
-vvv参数：php bin/hyperf.php start -vvv，日志首行会打印实际加载的task_worker_num - 运行中执行
curl http://127.0.0.1:9501/status（需开启server.status），查看task_worker_num和tasking_num - 用
swoole_get_local_ip()或Swoole\Server::stats()在代码里动态读取，避免被配置覆盖逻辑误导
最常被忽略的是：Swoole 5 默认启用 enable_reuse_port，多个 Master 实例可能共用端口，此时 ps 显示的进程数 ≠ 配置值 —— 要确认是否真启用了多实例模式。
