Hyperf 3.0 QPS 提升取决于协程调优：需确认 Swoole 协程启用、max_coroutine≥100000、worker_num设为swoole_cpu_num()*2、MySQL/Redis连接池扩容、启用Swoole JSON、使用PHP 8.1+ Attributes及严格类型返回。
Hyperf 3.0 在真实压测中 QPS 提升不是固定百分比，而是取决于你是否启用并调优了关键协程能力——没调优时可能只快 10%～20%，调优到位后可突破 10 万 QPS，是 2.2 的 3～5 倍。
协程运行时是否真正启用？
Hyperf 2.2 默认使用 Swoole 协程，但底层仍存在同步回退路径；3.0 强制要求 enable_coroutine => true，且默认关闭非协程兼容模式。若你在 3.0 中未显式开启或误配参数，实际运行仍是“伪协程”。
- 必须执行
php --ri swoole | grep "coroutine => enabled"确认输出为true -
server.php中max_coroutine至少设为100000，低于 50000 会导致高并发下协程创建失败，自动降级为同步阻塞 - 2.2 的
worker_num常设为 CPU 核数，3.0 推荐设为swoole_cpu_num() * 2（如 8 核 → 16），否则协程调度器争抢严重
连接池配置是否按压测反推？
2.2 的数据库/Redis 连接池默认值偏保守（如 MySQL max_connections 默认 20），3.0 不再容忍“先跑起来再说”。QPS 从 2 万冲到 10 万时，连接池若不扩容，会直接卡在 wait for connection from pool。
- MySQL 池：2.2 常用
min_connections=5, max_connections=20；3.0 建议min_connections=20, max_connections=200（对应 10 万 QPS 时平均每个协程仅占 2 连接） - Redis 池：2.2 默认
pool.max_connections=20；3.0 必须设为500并启用connection_pool选项，否则高频GET会排队阻塞 - 未启用连接池的
new Redis()调用在 3.0 下会被标记为阻塞操作，触发协程调度警告日志
JSON 序列化是否切换到 Swoole 原生？
2.2 完全依赖 PHP 原生 json_encode，大数组响应时 CPU 占满、无法协程让出；3.0 默认启用 Swoole JSON 扩展后，序列化耗时下降 2–3 倍，且全程不阻塞调度器。
- 验证是否生效：
php --ri swoole | grep "json => enabled"，无输出则需重编译 Swoole 或启用--enable-swoole-json - 控制器中避免直接
return $model，应先调用$model->toArray()，跳过访问器、隐藏字段等同步计算 - 对含 1000+ 条记录的列表，原生
json_encode可能单次耗时 80ms+，Swoole JSON 压缩后稳定在 25ms 内
注解与类型系统带来的隐性开销差异
2.2 使用 Doctrine Annotations，每次请求都要反射解析 PHPDoc；3.0 全面迁移到 PHP 8.1+ Attributes，注解在编译期处理，启动阶段就完成校验和缓存。
- 巨型项目（500+ Controller）在无扫描缓存下，2.2 启动耗时约 5 分钟，3.0 降至 10 秒内（DI 重构 + Attributes 零反射）
- 3.0 强制方法返回类型（如监听器
process(): void）、AMQP 消费者必须返回Result::ACK枚举，PHPStan 级别 7 可提前捕获 60%+ 类型错误，减少运行时异常导致的协程中断 - 同一文件混用 PHPDoc 注解和
#[Attribute]时，3.0 会静默忽略 PHPDoc，这点极易被忽略，导致路由/注入失效
真正拉开差距的从来不是版本号，而是你有没有关掉 enable_coroutine 的开关、有没有把连接池数字填对、有没有让 JSON 编码跑在协程里——这些地方错一个，10 万 QPS 就永远只是 benchmark 报告里的数字。
