结论：Webman 3 更适合高并发 API，CakePHP 5 不适合核心高并发接口；因 Webman 基于 Workerman 常驻内存、异步 I/O、低开销，实测 QPS 达 4.5 万+，而 CakePHP 依赖 FPM 重载、同步 ORM，QPS 难超 400。
直接说结论：高并发 API 场景下，Webman 3 是更合适的选择；CakePHP 5 不适合承担核心高并发接口角色。
这不是版本或功能的优劣问题，而是架构定位的根本差异。
Webman 3 天然为高并发 API 而生
它不是“能跑高并发”，而是“不按高并发设计就无法启动”。
- 基于 Workerman，进程常驻内存，onWorkerStart 初始化一次，无每次请求的框架重载、自动加载、容器重建开销
- 默认支持多 worker 进程 + 事件循环，I/O 就绪即处理，不阻塞整个进程（前提是用异步客户端）
- 实测纯 API 接口 QPS 可达 4.5 万+，数据库密集型（10 次查询）仍稳定在 1200+ QPS
- 内存占用低（峰值约 85MB），适合横向扩缩容和云原生部署
但要注意硬约束：
立即学习“PHP免费学习笔记（深入）”；
- 必须用连接池（如
workerman/mysql或hyperf/database协程驱动），否则 MySQL/Redis 连接数会迅速打满 - 慢 SQL 会卡死整个 worker 进程，必须加索引 + 异步 I/O + 超时控制
- 全局状态不能依赖普通静态变量，每个 worker 进程内存隔离
CakePHP 5 仍是传统 FPM 思维的全栈框架
它强在快速建站、约定优于配置、Bake 自动生成 CRUD，但不是为高并发优化的：
- 默认运行在 PHP-FPM 模式，每次请求都重新加载全部类、重建服务容器、解析配置、注册中间件
- 即使搭配 RoadRunner 或 Octane，QPS 也仅提升至 2000–3500 区间（远低于 Webman 的 1200+ 数据库型 QPS）
- ORM（CakePHP ORM）默认同步阻塞，没有协程或连接池支持，高并发下容易出现连接耗尽、超时堆积
- 缓存、日志、验证等组件虽完善，但在万级并发链路中会成为瓶颈点，且难以无感替换
简单对比一个真实场景：
用户下单接口需查用户、库存、优惠券、写订单、发消息。
- Webman 3：用
workerman/mysql异步查库 + Redis Lua 原子扣减 + GatewayWorker 推送，可压测到 800+ QPS（含事务）- CakePHP 5：同等逻辑在 FPM 下通常卡在 120–180 QPS；即使上 RoadRunner，因 ORM 和中间件链路过重，难突破 400 QPS
什么时候可以考虑 CakePHP 5？
- 项目以管理后台、内部工具、低频 BFF 层为主，QPS 长期低于 200
- 团队熟悉 CakePHP 生态，需要快速交付带权限、审计、导出等功能的业务系统
- 后端已由 Go/Java 承担高并发主接口，CakePHP 仅作轻量胶水层或前端 SSR 渲染
不复杂但容易忽略：选框架不是看文档多漂亮、生成器多好用，而是看它默认怎么处理第 1000 个并发请求——Webman 3 的答案是“早准备好了”，CakePHP 5 的答案是“得你手动重写一整套底层”。
