webman无法直面百万qps，因其协程仍受限单线程调度、连接池保守、无内置熔断，实测单机超8万qps即现超时与oom；它应仅作秒杀业务层，流量需由nginx/openresty前置拦截卸载。
Webman 本身不是为百万 QPS 秒杀场景原生设计的框架，直接用它扛住「瞬间百万级 QPS」不现实——这不是 Webman 的问题，而是任何 PHP 进程模型在纯同步阻塞 I/O 下的物理瓶颈。真要支撑这种量级，必须绕开 PHP 层做流量拦截与分层卸载。
为什么 Webman 无法直面百万 QPS
Webman 基于 ReactPHP，是多进程 + 协程模型，单机吞吐远高于传统 FPM，但仍有硬约束：
- PHP 协程仍受限于单线程调度（即使 Swoole 4.8+ 支持多线程协程，Webman 官方未默认启用）
- 每个请求仍需加载 Composer 自动加载、解析路由、实例化控制器——这部分无法完全规避
- Redis 连接池、MySQL 连接池在百万连接下极易打满，而 Webman 默认连接池配置偏保守（如
redis.pool.size默认 20） - 没有内置熔断/降级能力，一旦下游 Redis 或 DB 延迟升高，协程会堆积，最终 OOM
实测数据：单台 16C32G 机器，Webman + Redis Cluster + Swoole 4.10，在无前置拦截时，QPS 超过 8 万即出现协程超时、max_coroutine 达到上限、大量 SWOOLE_ERROR_SERVER_NO_AVAILABLE_WORKER 错误。
Webman 只能做「秒杀业务层」，不能做「流量入口层」
把 Webman 当成整个秒杀链路的唯一载体，等于让快递员去拦高铁——位置错了。正确分工是：
- CDN / Nginx 层：静态资源托管、IP 黑白名单、
limit_req令牌桶限流（例如限制单 IP 5qps） - OpenResty（Lua）层：验证码校验、用户资格预检（查 Redis 中
user:123:seckill:enabled）、秒杀开关控制（seckill:status） - Webman 层：仅处理「已通过所有前置校验」的请求，专注订单生成逻辑、调用 RocketMQ 生产者发送
seckill_order消息 - 独立消费者服务（Go/Java）：从 RocketMQ 拉取消息，执行库存扣减（Lua 脚本调用
DECRBY stock_1001 1）、落库、发通知
这意味着你在 Webman 里写的 SeckillController::do() 方法，代码行数应控制在 30 行以内，且不能含任何数据库查询或远程 HTTP 调用。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
Webman 内部必须关闭的默认行为
开箱即用的 Webman 配置对高并发是“友好但危险”的，上线前必须显式关闭或重配：
-
app.app_debug = false：Debug 模式下日志写入、异常堆栈收集会吃掉 30%+ CPU -
config/autoload/cache.php中禁用FileCache，改用RedisCache，并设置default_expire≤ 30 秒 -
config/autoload/database.php中 MySQL 的pool.max_connections不建议设超过 50；更推荐彻底移除 DB 依赖，用Redis::eval()执行 Lua 脚本完成库存原子操作 - 禁用所有中间件中含
file_get_contents、curl_exec、sleep()的逻辑——它们会阻塞整个 worker 进程
特别注意：Webman\Http\Response::withStatus(429) 不能用于限流响应，因为状态码写入发生在协程末尾；应由 Nginx 直接返回 429，Webman 根本不接收该请求。
RocketMQ 是 Webman 秒杀链路的「呼吸阀」
Webman 作为生产者，必须使用 RocketMQ 的异步发送（sendAsync）+ 本地重试（非 RocketMQ 重试），否则一个消息发送超时就会卡死当前协程。关键配置：
- 生产者组名必须带业务前缀，如
PG_seckill_webman_v1，避免和消费者组冲突 - 设置
retry_times_when_send_failed = 2，失败后丢弃消息并记录告警（不要无限重试） - 消息体必须极简：
["uid" => 123, "sku_id" => 1001, "ts" => 1747926488]，禁止序列化对象或嵌套数组 - 务必开启
trace_topic_enabled = false，Trace 功能在百万级下会产生海量元数据写入压力
最后提醒：RocketMQ Broker 端的 brokerRole=ASYNC_MASTER 是底线配置，SYNC_MASTER 会直接让吞吐归零。你看到的「成功下单」其实是消息写入成功，不是库存扣减成功——这个认知偏差，是绝大多数 Webman 秒杀项目线上翻车的第一原因。
