php原生无异步i/o，所谓“异步请求”实为curl_multi_exec并发、后台进程或swoole/reactphp扩展实现；调试关键在确认请求发出、响应捕获及错误不丢失。
PHP 本身没有原生的异步 I/O 模型（如 Node.js 的 event loop），所谓“异步请求”通常指：用 curl_multi_exec 并发多个 curl 句柄，或通过 proc_open/shell_exec 启动后台进程，或借助 ReactPHP/Swoole 等扩展。调试难点不在“是否并发”，而在「请求是否真正发出、响应是否被正确捕获、错误是否静默丢失」。
curl_multi_exec 并发时请求没发出去？检查句柄状态和循环逻辑
常见现象：调用 curl_multi_exec 后无任何响应，curl_multi_info_read 也读不到完成项。根本原因常是未正确进入 while 循环等待，或未及时调用 curl_multi_select 避免忙等。
实操建议：
- 必须用
do...while包裹curl_multi_exec，直到返回值为CURLM_CALL_MULTI_PERFORM或CURLM_OK - 每次
curl_multi_exec后，需调用curl_multi_select($mh, 1)阻塞等待 socket 就绪（参数1表示最多等 1 秒） - 在循环内用
curl_multi_info_read主动捞完成句柄，不能只靠curl_multi_exec返回值判断
do {
$mrc = curl_multi_exec($mh, $active);
if ($mrc == CURLM_CALL_MULTI_PERFORM) continue;
if ($mrc != CURLM_OK) break;
curl_multi_select($mh, 1);
} while ($active);
curl_multi_getcontent 返回空？确认是否已调用 curl_multi_remove_handle
现象：curl_multi_getcontent($ch) 总是返回 null 或空字符串。这不是 bug，而是因为该函数**仅在句柄已被 curl_multi_remove_handle 移除后才安全可用**。若提前调用，行为未定义（多数情况返回空）。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 务必在
curl_multi_info_read返回完成句柄后，先调用curl_multi_remove_handle($mh, $ch) - 再调用
curl_multi_getcontent($ch)获取响应体 - 最后用
curl_close($ch)释放资源
超时/SSL 错误被吞掉？必须显式检查每个句柄的 curl_error 和 curl_getinfo
使用 curl_multi 时，单个请求失败（如 CURLE_OPERATION_TIMEDOUT、CURLE_SSL_CONNECT_ERROR）不会中断整个多路复用器，也不会抛异常——错误被静默记录在句柄内部。不主动查，就永远不知道哪几个挂了。
实操建议：
- 对每个完成句柄，调用
curl_error($ch)检查错误消息 - 调用
curl_getinfo($ch, CURLINFO_HTTP_CODE)确认状态码是否为 200 - 特别注意
CURLINFO_CONNECT_TIME和CURLINFO_TOTAL_TIME，可定位是 DNS、连接还是响应慢
$err = curl_error($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if ($err || $httpCode >= 400) {
error_log("Request failed: {$err}, HTTP {$httpCode}");
}
想真异步？别硬套 curl_multi，优先考虑 Swoole 或 ReactPHP
如果业务需要高并发、长连接、事件驱动（比如同时处理 1000+ WebSocket 请求 + 调用第三方 API），curl_multi 的阻塞 select + 多句柄管理会迅速成为瓶颈。它本质仍是同步 I/O 的轮询模拟，不是真正的异步。
实操建议：
- 短期验证用
curl_multi没问题，但上线前务必压测 QPS 和内存占用 - 生产环境涉及持续异步任务（如轮询、消息推送），直接上
Swoole\Http\Client或React\Http\Browser - 注意：Swoole 的协程
Co\Http\Client不兼容传统curl函数，迁移需重写网络层
最易被忽略的一点：无论用哪种方式，“异步”不等于“不用管错误”。所有回调、协程 await、multi info read 的分支，都必须覆盖异常路径——否则线上故障时，你只会看到日志里一片空白。
