webman高并发靠事件驱动+常驻内存+异步i/o协同，同步操作如file_get_contents会阻塞事件循环，必须改用workerman/http-client等异步方案，并确保数据库、redis等所有i/o均异步化。
Webman 处理大量并发 HTTP 请求，靠的不是“加进程”或“堆配置”，而是事件驱动 + 常驻内存 + 异步 I/O 三者协同。它不依赖 PHP-FPM，单个 Worker 进程就能扛住数万连接——前提是你的业务逻辑别写成同步阻塞式。
为什么 file_get_contents 或 curl_exec 会拖垮并发能力
这是最常踩的坑：在 Webman 的回调里直接调用同步 HTTP 客户端，整个 Worker 进程会被卡住，无法响应其他连接。哪怕只卡 100ms，1000 个并发请求就可能排队雪崩。
- 同步调用（如
curl_exec）会让当前协程/线程完全阻塞，事件循环停摆 - Webman 默认每个 Worker 是单线程 + 协程调度（若启用 Swoole 或基于协程的扩展），但阻塞操作会绕过协程调度
- 真实压测中，用同步 HTTP 客户端的 Webman QPS 可能还不如 Laravel + FPM
必须用 workerman/http-client 发起异步请求
这是官方推荐、开箱即用的方案，底层复用连接池、自动管理 Keep-Alive、符合 PSR-7，且天然适配 Webman 的事件循环。
- 安装：
composer require workerman/http-client - 发起请求时不能
await（除非你启用了协程运行时），而应传回调函数处理响应 - 示例片段：
$client = new \Workerman\Http\Client();
$client->get('https://api.example.com/users', function ($response) use ($connection) {
$connection->send($response->getBody());
});
注意：$client 实例可复用，不要每次请求都 new 一个；连接池大小默认 10，高并发场景下可通过构造参数调整。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
数据库查询也得异步化，否则白搭
哪怕 HTTP 客户端改对了，如果数据库还是用 PDO::query 或 mysqli_query 同步执行，瓶颈立刻转移到 MySQL 连接上。Webman 本身不绑定 ORM，但你可以选支持异步的驱动：
- 用
spiral/database+spiral/roadrunner-http（需 RoadRunner 配合） - 更轻量的选择：接入
swoole/mysql协程客户端（需 Webman 运行在 Swoole 环境下） - 纯 Workerman 环境下，可封装基于
workerman/mysql的异步查询（它提供回调式 API，类似http-client）
关键判断标准：所有 I/O 操作（HTTP、DB、Redis、文件读写）是否都脱离了「等待返回才继续」的线性流程。只要有一个没切过去，整个并发收益就会断崖式下跌。
Worker 数量和进程模型不是越多越好
很多人一上来就设 'count' => 16，结果 CPU 上下文切换激增、内存占用翻倍，QPS 反而下降。Webman 的设计哲学是「少而精」：
- Worker 数量建议设为 CPU 核心数 × 1～1.5 倍（例如 8 核机器设 8～12）
- 每个 Worker 默认处理全部协议（HTTP/WS/TCP），混用时要注意资源争抢
- 若业务含重计算（如图像处理、加密解密），可单独拆出一个自定义进程，避免污染主 HTTP Worker
- 务必开启
opcache.enable=1和opcache.preload，否则每次请求仍会触发 opcode 编译开销
真正决定并发上限的，从来不是进程数量，而是单个 Worker 能否在毫秒级内完成「接收→非阻塞I/O→响应」这个闭环。任何阻塞点，都会成为整条流水线的节流阀。
