万级 QPS 是可复现的生产结果，但需确保压测走 HTTP 接口、使用 JMeter 命令行非 GUI 模式、配置合理线程组与堆内存，并结合 hyperf/metric 实时指标交叉验证协程、连接池及响应延迟。
万级 QPS 不是宣传话术，而是可复现的生产结果——但前提是压测方式、配置和链路都对。直连数据库或 GUI 模式跑 JMeter，测出来的数字毫无参考价值。
为什么 JMeter 必须走 HTTP 接口而非直连 MySQL
直连 MySQL 的压测绕过了 Hyperf 整个请求生命周期：路由匹配、中间件执行、协程上下文注入、DB 连接池复用、ORM 封装逻辑全被跳过。常见误导现象包括：
-
Communications link failure在直连时高频报错，但/api/user/{id}接口完全正常——问题实际出在连接池超时或max_connections配置不一致 - 直连压出 8000 QPS，而真实接口仅 1200 QPS，CPU/内存平稳——大概率是
max_coroutine触发排队，或worker_num设置过低 - P95 响应时间陡升但错误率为 0——说明协程资源耗尽，新请求在等待可用协程，不是 DB 慢也不是网络卡
JMeter 命令行压测必须加的三个关键配置
GUI 模式会因 Swing 线程和 JVM GC 反向拖慢结果，必须用命令行非 GUI 模式：
- 启动命令固定为：
jmeter -n -t test.jmx -l result.jtl -e -o report/ - 提前修改
jmeter.bat或jmeter.sh中的HEAP="-Xms2g -Xmx2g"，否则高并发下 GC 会污染 RT 数据 - 线程组必须用「Concurrency Thread Group」插件（非原生线程组），它能更稳定维持目标并发数；
Ramp-Up Period别设为 0，日常模拟建议 300 秒，给系统缓冲时间
hyperf/metric 指标必须和 JMeter 结果交叉验证
只看 JMeter 的 Aggregate Report 是盲人摸象。Hyperf 运行时指标才是瓶颈定位依据：
- 启用
hyperf/metric并设'use_standalone_process' => true，避免监控逻辑干扰业务协程 - 重点关注
coroutine.active（当前活跃协程数）是否持续逼近max_coroutine，逼近即表示协程资源吃紧 - 对比
db.pool.waiting和redis.pool.waiting，若长期 > 0，说明连接池容量不足或下游响应变慢 -
http.server.request.duration的 P99 值若远高于 JMeter 报告值，说明框架层有未捕获的阻塞点（比如漏掉协程化改造的file_get_contents）
真正卡住万级 QPS 的，往往不是 Swoole 版本或 CPU 核数，而是某处没切到协程的 sleep()、一个没配连接池的 Redis 实例、或者 max_coroutine 被设成了默认的 100000 却没结合 worker_num 动态调整。这些细节不拉出来对齐，压测数据就只是幻觉。
