可以,但需配合curl_multi_select实现真正并发;直接while(curl_multi_exec())会卡死,因缺少socket就绪等待;并发受超时设置、系统限制、服务器反爬及PHP单进程影响;高并发建议用Swoole协程或amphp。

curl_multi_exec 能否真正并发请求?
可以,但不是“开箱即用”的并发——curl_multi_exec 本身不自动并行,它只是把多个 cURL 句柄交给底层 libcurl 批量轮询处理,是否并发取决于你是否配合 curl_multi_select + 循环等待,否则容易卡死或退化成串行。
为什么直接 while(curl_multi_exec()) 会卡住?
常见错误是写成:
while (curl_multi_exec($mh, $active) === CURLM_CALL_MULTI_PERFORM);这种写法只适用于“立即完成”的极少数情况;绝大多数 HTTP 请求需要等待 socket 就绪,而
CURLM_CALL_MULTI_PERFORM 已被弃用(PHP 7.5+ 报警告),且无法触发真正的异步等待。
正确做法是:用 curl_multi_select 阻塞等待任意句柄就绪,再调用 curl_multi_exec 处理已就绪的请求:
-
curl_multi_select返回 >0 表示有 socket 可读/可写,此时再curl_multi_exec - 返回 0 表示超时(需设合理 timeout,如 1 秒),应检查是否还有活跃句柄
- 返回 -1 表示 select 失败(如无可用 socket),通常可重试或 break
实际并发数受哪些因素限制?
并发能力不只看代码逻辑,还卡在这些地方:
立即学习“PHP免费学习笔记(深入)”;
-
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 3000)—— 单个请求超时太长,会拖慢整体吞吐 - 系统级限制:
/proc/sys/net/core/somaxconn、本地端口耗尽(特别是短连接)、DNS 解析阻塞(建议加CURLOPT_DNS_CACHE_TIMEOUT) - 目标服务器反爬策略:同一 IP 短时间内高频请求可能被限速或封禁,和 curl 是否并发无关
- PHP 自身:单进程模型下,CPU 密集型操作(如大量 JSON 解析)会挤占 I/O 时间,建议把解析逻辑放到
curl_multi_info_read后做
有没有更简单的替代方案?
如果只是想发几个 HTTP 请求并等全部返回,curl_multi 是最轻量的原生方案;但若要稳定支撑高并发、带重试/熔断/连接池,别硬刚:
- PHP 8.1+ 可考虑
Swoole\Coroutine\Http\Client,协程天然适合 I/O 并发 - 不想引入扩展?用
amphp/http-client(基于事件循环),比手写 multi 更健壮 - 简单脚本场景,甚至
shell_exec('curl & curl & wait')都比写错的curl_multi更可靠
真正难的从来不是“怎么发多个请求”,而是“怎么让它们不互相干扰、不压垮自己、失败了还能知道哪一趴挂了”。curl_multi_info_read 的错误提取、句柄清理、资源释放,才是实际项目里最容易漏掉又最难 debug 的部分。











