Hyperf性能优化需从协程行为、资源复用、数据路径三层面系统性收敛，避免伪异步；协程池配置须匹配业务特征，HTTP禁用Cookie共享，Redis启用超时，数据库规避N+1和全量加载，异步任务需防争抢，监控须覆盖协程生命周期关键指标。
Hyperf性能瓶颈优化不是靠堆配置或换组件，而是从协程行为、资源复用、数据路径三个层面系统性收敛问题。核心在于避免“伪异步”——表面用了协程，实际仍阻塞、争抢、重复开销。
协程池配置必须匹配业务特征
数据库、Redis、HTTP客户端的连接池不是越大越好，而是要与并发峰值和单次请求耗时匹配。例如：平均响应200ms的服务，QPS 500时，理论最小连接数 ≈ 500 × 0.2 = 100；若池子设为200，空闲连接会持续占内存；若只设50，就会频繁等待连接释放。
- 检查
config/autoload/databases.php中pool.min_connections和max_connections是否按压测结果调整，而非沿用默认值 - HTTP客户端连接池需禁用 Cookie 共享（
cookies => false），否则跨请求污染导致下游返回异常，这是生产环境高频踩坑点 - Redis 连接池建议开启
connect_timeout和wait_timeout，防止慢节点拖垮整个池
数据库操作必须规避 N+1 和全量加载
Eloquent 在协程环境下放大了传统ORM的性能缺陷：一个未显式约束的关联查询，可能触发数十次串行查询；一个 select(*) 可能将 MB 级数据从MySQL拉到PHP内存再丢弃。
- 使用
with(['relation' => fn ($q) => $q->select(...)])显式控制关联字段 - 批量写入统一走
insert()或upsert()，禁用循环create() - 分页场景优先用游标分页（
cursorPaginate()），避免offset越大越慢
异步任务不能盲目开协程
协程不是万能加速器。在共享资源（如 Redis 连接池、全局锁、文件句柄）上无节制并发，反而引发争抢、超时、连接枯竭。
- 对同一 Redis key 的高频读写，不要为每条记录起独立协程；应合并请求或加本地缓存层
- 队列消费者中，
max_messages和handle_timeout需配合业务逻辑时长设置，避免单次消费过久阻塞后续消息 - 耗时外部调用（如第三方API）建议封装为独立异步任务，而非在 HTTP 请求协程内直接
go()
监控必须覆盖协程生命周期关键指标
仅看 QPS、内存、CPU 无法定位协程级瓶颈。真正有效的指标是：
- 当前活跃协程数（
swoole_server_stats().coroutine_num）是否长期 > 5000？过高说明有协程未及时结束 - 协程等待时间（
co_wait_time）突增，大概率是连接池不足或下游响应变慢 - Redis/DB 连接池的
used_connections持续接近max_connections，就是明确扩容信号
这些指标可通过 Hyperf 内置 metrics 组件暴露给 Prometheus，再用 Grafana 做阈值告警。
