Hyperf 3.1扛数百QPS需全链路调优：显式配置MySQL连接池（min=5/max=50）、验证PDO非持久化、debug/pool接口确认连接数波动；JMeter压测需设200线程+聚合报告，结合Co::stats()与MySQL慢日志分层定位瓶颈；限流须全局配置rate_limit.php并独立Redis连接池；硬性检查点包括--workers=4、opcache启用及task_worker_num≥4。
要让Hyperf 3.1服务在真实流量下扛住每秒数百请求，不能只靠框架默认配置——得从协程调度、连接池、Redis预热到JMeter压测脚本全链路调优。
Hyperf中启用协程MySQL连接池并验证是否生效
第一步：修改config/autoload/databases.php，将'driver' => 'mysql'对应项下的'pool' => ['min_connections' => 5, 'max_connections' => 50]显式写出，不依赖框架默认值。
第二步：在控制器里用DB::connection()->getPdo()获取PDO实例后，立刻调用getAttributes()检查PDO::ATTR_PERSISTENT是否为false——Hyperf协程池要求禁用持久连接，否则会复用非协程安全的底层资源。
第三步：启动服务后执行curl -X GET http://127.0.0.1:9501/debug/pool?name=mysql，返回JSON中total_connections字段必须大于0，且idle_connections随并发请求波动——若始终为0，说明协程池未被触发，大概率是业务代码里用了new PDO()硬编码绕过了连接池。
用JMeter压测Hyperf接口并定位QPS瓶颈
方法一：基础压测脚本配置
新建线程组→设置线程数为200、Ramp-Up时间为10秒、循环次数为永久；HTTP请求取样器填入目标URL；添加“聚合报告”监听器；运行后观察“平均响应时间”是否稳定在20ms内、“错误率”是否低于0.1%。
方法二：关键指标埋点验证
在app/Command/BenchmarkCommand.php中插入Co::stats()调用，打印coroutine_num和total_yield_count——若前者长期卡在10以下而后者飙升，说明协程频繁让出但无新协程创建，根源常是Redis或MySQL连接池耗尽，而非CPU瓶颈。
方法三：分层排查路径
① 先关闭所有中间件（注释config/autoload/middlewares.php中除GlobalHttpMiddleware外全部），压测QPS提升明显→问题在中间件逻辑；
② 保留中间件但注释掉数据库查询语句，QPS恢复→确认数据库是瓶颈；
③ 【必须做】在MySQL慢日志中开启long_query_time=0.01，再压测，抓出所有超10ms的SQL——Hyperf协程模型下，单条慢查会阻塞整个协程，比传统FPM更敏感。
Hyperf中实现接口限流防雪崩
使用hyperf/rate-limit组件时，不要直接在Controller方法上加@RateLimit注解——这会导致每个请求都走AOP代理，增加协程切换开销。
正确做法是在config/autoload/rate_limit.php中配置全局规则：'default' => ['max_attempts' => 100, 'decay_minutes' => 1, 'key' => 'ip']，然后在路由定义中绑定：Router::addRoute(['GET'], '/api/v1/user', 'App\Controller\UserController@info')->middleware(RateLimitMiddleware::class);
注意：Redis连接必须单独配置连接池（config/autoload/redis.php中'pool' => ['min_connections' => 2, 'max_connections' => 10]），否则限流中间件会因Redis阻塞拖垮整个服务。
Hyperf压测中发现QPS上不去的三个硬性检查点
第一，检查bin/hyperf.php start启动时是否带--workers=4参数——Hyperf默认仅启1个Worker进程，即使CPU有8核也只用1核；
第二，php.ini中opcache.enable=1且opcache.memory_consumption=256必须生效，用php -i | grep opcache确认；
第三，【致命项】确保config/autoload/server.php里'settings' => ['task_worker_num' => 4]已设置——压测时大量异步任务（如日志写入、MQ推送）若堆积在主Worker中，会直接吃光协程栈内存，导致QPS断崖下跌。
