Webman单机并发性能远超Laravel和ThinkPHP，源于常驻内存架构与FPM模式的本质差异：实测QPS达Laravel（FPM）的31倍、ThinkPHP8的13倍；其onWorkerStart仅进程级执行一次，需配合连接池与异步I/O，否则易触发连接数耗尽、状态不一致等问题。
Webman 单机并发性能远超 Laravel 和 ThinkPHP，不是“稍快一点”，而是架构层面的代际差——它不走 PHP-FPM 模式，没有每次请求都重载框架、重建容器、重复自动加载的开销。实测中，同等硬件下 Webman 的 QPS 是 Laravel（FPM）的 31 倍、ThinkPHP 8 的 13 倍，数据库查询场景也能稳定高出 2–3 倍。
Webman 的 onWorkerStart 和 Laravel/TP 的启动钩子根本不是一回事
很多人把 onWorkerStart 当成 Laravel 的 AppServiceProvider::boot() 或 ThinkPHP 的 App::beforeStart() 来用，结果连接数爆满、内存泄漏、状态错乱。关键区别在于：
-
onWorkerStart在每个 Worker 进程启动时只执行一次，之后所有请求共享该进程内的变量、DB 连接、Redis 实例等资源 - Laravel/TP 的启动钩子是「请求级」的，每次请求都重新执行，天然隔离，但代价是重复初始化
- 在
onWorkerStart里直接 new PDO 或 new Redis？没做连接池的话，16 个 worker 就可能占满 MySQL 的max_connections - 想存全局状态？别用普通数组或静态属性——每个 Worker 进程是独立内存空间，A 进程改了，B 进程看不到
压测失败率飙升，大概率不是代码问题，而是系统句柄或连接池卡住了
用 wrk 或 Apifox 压到 1000+ 并发时，Connection refused 或 Too many open files 错误频出，第一反应不该是调高 $worker->count，而应检查底层资源瓶颈：
- 先看本机限制：
ulimit -n，开发机默认常为 1024，生产环境建议设为65535（需同步修改/etc/security/limits.conf） - 查实际连接数：
netstat -an | grep :8787 | wc -l，接近系统上限就说明 socket 耗尽 - 确认 DB 连接是否复用：每个 Worker 若独占 10 个 PDO 连接，开 8 个 worker 就是 80 个连接；MySQL 默认
max_connections=151，很容易打满 - Redis 同理，
redis-cli info clients | grep connected_clients看真实连接数，别依赖客户端自动释放
数据库查询慢，别急着优化 SQL，先看是不是阻塞式调用
Webman 支持异步 I/O，但默认的 pdo_mysql、mysqli、think-orm 全是同步阻塞的。哪怕你开了 16 个 worker，一个慢查询仍会让整个进程卡住，其他请求排队等待：
立即学习“PHP免费学习笔记（深入）”；
- 必须换异步驱动：用
workerman/mysql替代原生 PDO，或用hyperf/database配合协程 MySQL 客户端 - ThinkPHP 项目迁过来后，
Db::table()->select()看似一样，但背后是同步调用，QPS 会断崖下跌 - 日志组件也得小心：
monolog默认同步写文件，高并发下磁盘 I/O 成瓶颈，建议切到webman/logger或异步 file handler - 压测时观察
top中的 %CPU 和 %WAIT，若 %WAIT 高，说明在等 I/O，不是 CPU 不够
真正卡住 Webman 性能的，往往不是框架本身，而是开发者沿用 FPM 习惯写的同步逻辑、未收敛的连接管理、以及被忽略的操作系统级限制。常驻内存不是免费午餐，它把资源控制权交还给了你——谁初始化、谁复用、谁销毁，都得自己心里有数。
