Webman性能优势源于常驻内存、多进程事件循环、异步I/O及Swoole协程四大机制：启动时一次性加载框架与连接池，省去FPM重复开销；默认4 Worker+epoll可支撑5万空闲连接；启用async插件实现数据库异步调用；Swoole协程使QPS从3.2万升至6.8万，但需规避阻塞函数。
你想知道Webman在PHP框架性能对比中为何能甩开Laravel、ThinkPHP几十倍QPS，又担心它是否真能在生产环境扛住万级并发——这篇文章只讲它性能表现的硬核来源和真实代价，不吹不黑，不绕弯子。
常驻内存：省掉90%重复加载开销
启动Webman服务后，整个框架代码、路由表、配置、数据库连接池全部留在内存里，后续每个请求都不再执行require、new App()、registerProviders()这些动作。
传统FPM模式下，一个Laravel请求要加载约1200个PHP文件，初始化37个服务提供者；Webman只需在启动时做一次，之后每次请求跳过这整套流程。
这一步不可逆——【一旦启动，所有全局变量、静态属性、已建立的PDO连接都持续存在】，意味着你不能在控制器里写static $cache = []然后指望每次请求清空，否则会累积泄漏。
立即学习“PHP免费学习笔记（深入）”；
多进程+事件循环：单机轻松跑满万级连接
Webman默认启用4个Worker进程（可通过config/process.php调整），每个进程内嵌一个基于libevent或ext-event的事件循环。
方法一：用epoll模型（Linux推荐）
确保系统已安装php-event扩展 → 启动时自动启用epoll → 单Worker可维持5万+空闲TCP连接。
方法二：退化为select模型（无扩展时）
无需额外安装 → 兼容性好 → 但单Worker连接上限压到1024，高并发场景必须增开Worker数。
注意：Worker进程数不是越多越好。超过CPU核心数后，进程切换开销反超收益，实测8核服务器设6～8个Worker最稳。
异步I/O支持：数据库/HTTP调用不再卡主线程
第一步：安装webman/async插件composer require webman/async
第二步：在控制器中使用异步MySQL客户端
调用Db::queryAsync("SELECT * FROM users WHERE id = ?", [$id]) → 数据库查询发起后立即返回，事件循环转去处理其他请求 → 结果就绪时触发回调。
第三步：混合阻塞与异步逻辑要小心
若在同一个请求中既用了Db::query()（阻塞）又用了Db::queryAsync()（非阻塞），后者不会提速，因为阻塞调用已让当前Worker停摆。
这一步操作起来很简单，直接把文件拖进去就行。但【未启用async插件时，所有数据库操作默认仍是同步阻塞】，压测看到的“高QPS”仅来自轻量路由和内存复用，不代表真实业务场景。
协程加持（Swoole版）：QPS翻倍的关键开关
① 确认已安装Swoole扩展（≥v5.0）且启用enable_coroutine
② 修改start.php，将Worker::runAll()替换为Swoole\Runtime::enableCoroutine(); Webman\App::run();
③ 所有PDO连接自动升级为协程MySQL客户端，file_get_contents、cURL等IO操作自动协程化
④ 原本需手动写的异步回调，现在可用go(function () { ... })直写同步风格代码
实测同一API接口，在纯Workerman模式下QPS为3.2万，开启Swoole协程后跃升至6.8万——提升来自IO等待期间的CPU时间复用，而非单纯加进程。
但要注意：Swoole协程模式下，sleep()、usleep()会被拦截转为协程挂起，而time_nanosleep()仍会真正阻塞，务必避开。
