concurrent.limit是Hyperf异步队列中控制每进程内真正并行执行任务数的核心参数，其值需根据任务平均耗时与目标QPS反推，并结合IO/CPU密集型特征差异化配置，盲目调高反而加剧IPC压力和丢任务风险。
Hyperf异步队列在高并发场景下容易因任务堆积导致延迟飙升甚至丢任务，必须通过concurrent.limit精准控制同一时刻真正并行执行的任务数，而不是靠盲目增加进程或协程数量。
理解concurrent.limit的真实作用
concurrent.limit不是“最多开多少个协程”，而是“同一时间最多有几个任务在handle()方法里执行”。它由消费者进程内的协程池统一调度，超出限制的任务会排队等待空闲槽位。
设为10不代表能扛住每秒1000任务——若单个任务平均耗时2秒，理论吞吐量上限就是5 QPS（10 ÷ 2）。盲目调高该值只会加剧IPC压力和内存占用，不解决根本瓶颈。
配置concurrent.limit的三步法
第一步：确认当前任务平均执行耗时
在Job类的execute()方法开头加microtime(true)，结尾再取一次，差值即真实耗时。避免用sleep()模拟，它不触发协程让出，会严重误导测量结果。
第二步：按吞吐目标反推合理值
假设你期望稳定支撑每秒30个任务，实测平均耗时1.5秒，则concurrent.limit ≥ 30 × 1.5 = 45。但【不要直接设45】——先设为20，观察监控指标再阶梯上调。
第三步：绑定监控验证效果
启动后紧盯hyperf.async_queue.concurrency指标（Prometheus）或日志中“Concurrent limit reached”频次。若该值持续满载且task_wait_queue_len > 0，说明limit偏低；若limit设到60但实际并发长期卡在8，说明瓶颈在DB/Redis连接池或任务内部阻塞调用。
两种典型场景的配置策略
方法一：IO密集型任务（如发邮件、调第三方API）
可设较高值（30～100），但必须配合协程化客户端（如hyperf/guzzle）。若混用同步curl或PDO直连MySQL，再高的limit也无效——协程会被阻塞挂起，实际并发数暴跌。
方法二：CPU密集型任务（如图像压缩、JSON解析大文件）
【务必设低，建议≤worker_num】。每个任务独占CPU时间片，协程无法缓解争抢。设过高会导致任务排队时CPU空转，响应延迟翻倍。此时应优先拆分任务粒度或移至Task Worker处理。
避坑：别被processes参数迷惑
config/autoload/async_queue.php里的processes控制的是消费者进程数量，不是并发能力。设为5只是启5个独立进程，每个仍受各自concurrent.limit约束。误以为“开5个进程=并发50”，结果5个进程全卡在Redis连接超时上——根源是redis.pool.max_connections没同步放大。
processes与concurrent.limit无直接换算关系。一个processes=1 + concurrent.limit=50，通常比processes=5 + concurrent.limit=10更稳——减少进程间资源竞争，降低上下文切换开销。
